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In this Issue 

Can the majority of people ever be as comfortable using a personal computer 
as they are driving a car? Most people would say that the computer industry 
has a long way to go to achieve this goal. However, the subject of the first 
nine articles in this issue — the HP NewWave environment — is a truly giant 
step in that direction. Instead of seeing the computer as a pile of hardware 
supporting multiple application programs that can be used to accomplish 
complex tasks if the user is knowledgeable enough, the NewWave user sees 
the computer as a single tool able to perform multiple complex tasks. The 
NewWave user interface is modeled on an ordinary office, offering a filing 
cabinet, a wastebasket, a printer, and other common functions, along with an uncommon staff 
member, a software robot called an "agent," which acts as a personal assistant for the user. In 
the NewWave Office, icons representing tasks performed by application programs are displayed 
along with icons representing basic office functions. Supporting this user interface but unseen by 
the user is an advanced architecture that specifies how applications are designed for the NewWave 
environment and how they are managed within it. Applications, tasks, and basic functions are 
treated as objects, and a transparent but powerful object management facility orchestrates the 
objects to accomplish what the user wants, switching between applications as necessary. The 
agent acts somewhat like the macro facilities offered by some applications, but it is much more 
powerful because it can use many applications and data sources, interacting with the object 
management facility through a NewWave architectural component called the application program 
interface. Another NewWave component is an advanced help facility. When the user wants help, 
it isn't necessary to determine which application to ask; the user simply asks the computer. An 
overview of the HP NewWave environment is presented in the article on page 6. For the conceptual 
and object models behind the object-based user interface, see page 9. Concepts and features 
of the object management facility and the NewWave object-based file system can be found in 
the article on page 17. For the design of the NewWave Office, see page 23. The technical details 
of the agent, the application program interface, and the agent command language can be found 
in the articles on pages 32 and 38, and the help facility is described in the article on page 43. 

For the NewWave environment to provide the hoped-for benefits to the user, application pro- 
grams must be designed to work within it. Existing applications, particularly those written for the 
Microsoft Windows environment upon which the NewWave environment is based, can be "encap- 
sulated" and gain some of the NewWave benefits, but not all. How encapsulation works is detailed 
in the article on page 57. NewWave designers have also addressed the question of how the 
NewWave architecture can aid in the development and delivery of computer-based training. This 
is the subject of the article on page 48. 
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The NewWave environment is an example of object-oriented software. Object-oriented software 
technology, which includes both programming languages and development methods, is becoming 
more widely accepted for software development. It has proved to be both productive and powerful, 
and it offers useful new approaches to the problems of code reuse and software maintainability. 
In the paper on page 87, Tom Kraemer gives us an introduction to object-oriented software 
technology and an example of its use in the development of the HP VISTA software for the HP 
3565S Signal Processing System. 

We first encountered the design story of the HP 9145A Quarter-Inch Cartridge Tape Drive in 
a paper presented at the 1988 HP Software Engineering Productivity Conference. The paper 
described the use of structured software design methods for the tape drive's real-time firmware. 
The article on page 79 is based on that paper. The hardware side of the design story is told in 
the article on page 67. Achieving the objectives — doubling the speed and cartridge capacity of 
an existing product — required a new tape cartridge with new media, tighter component and 
assembly tolerances, and new manufacturing processes. An extensive reliability assessment 
program verified the new design and continues to ensure the drive's reliability (page 74). 

R.P. Dolan 
Editor 



Cover 

The cover shows the displays that would appear when a NewWave Office user opens a file 
drawer, selects a folder, and chooses a document to edit — operations performed in a typical office 
environment. The example shows a complex document, that is, it contains text and graphics. The 
NewWave user does not have to select an application and then the document, but only the 
document. The NewWave environment handles associating the document with the application. 



What's Ahead 

The October 1 989 issue marks the Hewlett-Packard Journal's fortieth anniversary. The first issue 
was in September 1949. This is also HP's fiftieth anniversary year. To celebrate this double 
anniversary, we'll have a special article recapping some of the highlights of those years for both 
the company and the publication. We'll also present six papers from the 1988 HP Technical 
Women's Conference, the first conference of its kind at HP. The papers address a variety of 
hardware, software, and process management topics. Eight articles will cover the hardware and 
firmware design of the Performance Signal Generator family, consisting of the HP 8644A, 8645A, 
and 8665A Synthesized Signal Generators. A distinguishing feature of these instruments is a 
single phase-locked loop design, in contrast to the multiple-loop designs formerly used. 
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An Overview of the HP NewWave 
Environment 

The NewWave environment allows users to concentrate on 
the task and not the computer system. For developers of 
new applications, it provides the facilities to integrate 
applications into the the NewWave environment. 

by Ian J. Fuller 



THE NEWWAVE ENVIRONMENT is a comprehensive 
system developed by HP to provide a new level of 
flexibility and ease of use in our business systems. 
This article presents the history, the motivation, and an 
overview of the features and major components of the New- 
Wave environment. The other NewWave articles in this 
issue discuss the components of the NewWave architecture 
in detail. 

To understand the NewWave environment it is helpful 
to review the background for HP's decision to invest in 
this product. HP has been producing office systems soft- 
ware since the late 1970s. Some early products include the 
Design Systems Graphics package (DSG) and the HP Word 
word processing package, both of which run on HP 3000 
Computers. In personal computer software, the CP/M*- 
based HP 125 Business Assistant, which was released in 
1982, had a number of business software solutions, includ- 
ing word processing, a spreadsheet application, and a pre- 
sentation graphics package. 

The release of HP DeskManager for HP 3000 Computers 
in 1982 marked HP's first product that addressed the need 
for integrating these office systems software products. HP 
DeskManager was originally designed as a simple elec- 
tronic mail product, 1 allowing users to send and receive 
messages easily across a network of HP 3000 Computers. 
It was very clear that our customers needed more than 
electronic mail functions from HP DeskManager. They 
needed to be able to compose arbitrary packages of informa- 
tion into messages and to file those messages for later re- 
trieval. The introduction of new software on the HP 3000 
and on our personal computers meant that we needed to 
integrate the products mentioned above with HP DeskMan- 
ager. At the very least, users should be able to create and 
read an HP Word document within the HP Deskmanager 
environment without leaving the product. Over the years 
HP has invested very heavily in HP DeskManager, evolving 
it into a true integrated office system. It has a wide range 
of features and acts as the center of our HP 3000-based 
office solutions with close links to the personal computer. 

To enable users to connect their personal computers to 
the HP 3000, HP developed the Personal Productivity 
Center range of products. For the HP 3000 Computer these 
products include HP DeskManager, HP File/Library, HP 
Schedule, and Resource Sharing. For PC users these prod- 
ucts include software packages for electronic mail, terminal 



emulation, word processing, data management, spread- 
sheets, and graphics. 

There are a number of architectural limitations in the 
current products that prevented us from creating the truly 
integrated and powerful system our customers need. The 
products that we have available were designed in different 
HP divisions and by outside companies to meet the needs 
of their particular markets. This resulted in software appli- 
cations that did not have the same basic architecture. 

An investigation of potential solutions to the problem of 
integrating our products began with the knowledge that 
the solution developed must have the following fundamen- 
tal characteristics: 

■ It must be practical. The solution must work well on 
existing hardware and add value to existing software so 
that customer investments are protected. 

■ It must be flexible and extendable. The software field is 
expanding rapidly and opportunities will exist tomor- 
row that could not have been dreamed of when the sys- 
tem was designed. This includes portability across differ- 
ent hardware platforms. 

H It must allow for the efficient development of systems. 
Software components must be available for reuse accord- 
ing to the maxim that if a function is used several times 
in a system it should be provided as a system service 
for use by all components. 

© 
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Fig. 1 . Microsoft Windows environment. MS Windows enables 
users to isolate applications from the details of the hardware 
and provides a graphical user interface and multitasking 
under the MS-DOS operating system. 
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■ It must have a sufficient advantage over existing systems 
that customers and software developers will make the 
investment necessary to use the new system. 

■ It must allow us to build easy-to-learn and easy-to-use 
software. Users do not want to spend weeks or months 
learning to use software, and once they are proficient 
with the software, they do not want to be hampered by 
an inflexible system. 

■ It must be an open system. HP could not hope to offer 
proprietary solutions in all areas. Customers would want 
to take advantage of our architecture. Designing an open 
system from the start would allow many more solutions 
than we alone could provide. 

■ It must run on existing hardware such as the HP Vectra 
and the IBM PC/AT. 

This is a formidable list of objectives. The NewWave 
environment is designed to meet these objectives, and ex- 
ceed them wherever possible. 

Open and Extendable Architecture 

The NewWave environment was originally designed as 
a proprietary environment for the development of better 
integrated office systems. However, as prototypes of the 
system became available and were demonstrated, it became 
clear that the system had great appeal to a wider audience 
than the internal HP community. Major accounts and inde- 
pendent software vendors (ISVs) all wanted to learn how 
to write NewWave applications. They wanted to take ad- 
vantage of our object-based file system and applications, 
while addressing areas of the market that were their spe- 
cialty. 

We decided to open up the NewWave architecture. This 
entailed: 

■ Ensuring that our interfaces were made general and 
robust 

■ Providing documentation, training, and support suitable 
for software developers 

■ Doing extensive testing of the programmatic interfaces 
in different software and hardware environments. 
The NewWave environment will be used by a wide vari- 
ety of customers, all with different needs, and we know 
that our customers developing applications to run in the 
NewWave environment will expect us to keep up with new 
technologies. 

Based on the Microsoft® Windows interface (see Fig. 1), 
the NewWave environment is well positioned for IBM's 
OS/2 operating system and the Presentation Manager sys- 
tem from IBM and Microsoft. We are also working on im- 
plementing the NewWave environment under the HP-UX 
operating system. Thus, the NewWave environment pro- 
vides software developers with the advantage of a system 
that is portable across a range of platforms. 

The NewWave environment is extendable to incorporate 
new software techniques. For example, the agent facility, 
which is a major component in the NewWave architecture, 
is designed to include the functionality and power of arti- 
ficial intelligence. Future applications, such as natural lan- 
guage systems, can be integrated with NewWave applica- 
tions that use the agent facility without any impact on the 
application. 



The System Approach 

From the beginning the NewWave environment has been 
designed as an integrated software system. This is in con- 
trast to previous systems, which were designed piecemeal, 
with integration added later. The major components of the 
NewWave architecture are shown in Fig. 2. Taken together, 
these components offer software developers and users a 
number of benefits, including: 

■ Consistency. NewWave applications have a consistent 
user interface, based upon Microsoft Windows. HP pro- 
vides user interface rules that are an extension of those 
provided by Microsoft to ensure that NewWave applica- 
tions have a common look and feel. Common data for- 
mats adopted by NewWave applications ensure that in- 
formation generated in one area can be understood in 
another, even if it is on a different machine in another 
location. 

■ Automation and Training. The agent facility provides 
task automation across all applications in the NewWave 
environment. The agent can be thought of as a personal 
assistant that can perform tasks on behalf of the user. 
Computer-based training (CBT) is implemented in the 
NewWave environment using the facilities provided by 
the agent. The NewWave environment provides the tools 
for developers to use the agent and to build CBT into 
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Fig. 2. The NewWave environment. The NewWave environ- 
ment is built on the industry-standard IBM PC/AT compatible 
platform. It uses MS Windows to obtain a graphical user inter- 
face consistent with the OS/2 operating system and the forth- 
coming Presentation Manager system from IBM and Micro- 
soft. The object management facility (OMF) provides the ob- 
ject-oriented capability of the NewWave environment, and 
allows any kind of data to be treated as an object and rep- 
resented on the screen as an icon (e.g., text, graphics, 
spreadsheet, image, voice, etc.). OMF also provides applica- 
tion and data binding, information links, and instant integra- 
tion. The application program interface (API) provides a set 
of systemwide services for applications in the NewWave en- 
vironment. These services include task automation, context 
sensitive help, and computer-based training (CBT). 
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their products. The agent is described in the articles: 
"An Extensible Agent Task Language" and "Agents and 
the HP NewWave Application Program Interface" on 
pages 38 and 32 respectively, and computer-based train- 
ing is discussed in the article "NewWave Computer- 
Based Training Development Facility" on page 48. 

■ Developer Productivity. The NewWave environment 
handles many of the tasks that developers would have 
to design and implement individually if they were writ- 
ing applications outside of the NewWave environment. 
An example of this is the NewWave help facility. New- 
Wave help is available to all NewWave applications and 
provides a powerful context sensitive help capability in 
all areas of the system. The help facility is described in 
the article "The HP NewWave Environment Help Facil- 
ity" on page 43. 

a Integration. The NewWave object management facility 
(OMF) provides standardized data object management 
for all NewWave applications. The OMF includes 
facilities to define and install specific classes of objects, 
such as text, graphics, image, or voice, and the links 
between them. For example, a text object can incorporate 
an arbitrary number of other objects to produce a com- 
pound document. The OMF manages the links so that 
the object can be manipulated as a whole when it is 
copied, deleted, or mailed over the network. The OMF 
also supports data-passing links so that, for example, a 
spreadsheet object can obtain data from a data base and 
in turn link that data into a document or a line chart. 
These facilities are all supported at the system level and 
thus are available to all NewWave applications. The 
OMF is described in the article "The NewWave Object 
Management Facility" on page 17. 

■ Ease of Learning. A major objective of the NewWave 
environment is to ensure that if users learn a technique 
in one area, they will be able to apply the same tech- 
niques in another area, even if the application is not 
supplied by HP. The computer-based training tools are 
available to all developers so that they can build these 
powerful learning aids into their products. 

a Ease of Use. The NewWave environment is designed to 
be substantially easier to use than previous systems. We 
selected an interface based upon direct manipulation of 
icons that represent NewWave objects (e.g., file drawers, 
folders, printers, etc.). From the user's perspective the 
NewWave Office window provides an easy-to-use facil- 
ity for organizing, filing, retrieving, and deleting objects 
as necessary. The NewWave Office is the primary inter- 
face between the user and the NewWave environment, 
and it is the first display seen by the user when the 
environment is loaded. The NewWave Office allows 
users to focus on the tasks that they need to perform 
rather than the tools they use. See the article "The New- 
Wave Office" on page 23 for more details. 

■ Integration with MS-DOS Applications. The NewWave 
environment offers a set of facilities that enable MS-DOS 
applications to be used within the system. At the 
simplest level users can access non-NewWave applica- 
tions from the NewWave Office window and return to 
the NewWave Office when they have completed their 
task. The data from non-NewWave programs can also 



appear as objects in the OMF. HP provides facilities to 
encapsulate non-NewWave applications within a shell 
that allows them to share some of the NewWave environ- 
ment advantages such as data linking and background 
printing. Integration with MS-DOS applications is de- 
scribed in the article "Encapsulation of Applications in 
the NewWave Environment" on page 57. 

Supported Hardware Platforms 

The initial release of the HP NewWave environment is 
designed to run on any Intel 80286 or 80386-based personal 
computer that supports Microsoft Windows. The primary 
platform is the HP Vectra range of personal computers. 
However, the NewWave environment is also supported on 
the IBM PC/AT and IBM OS/2 series and HP Vectra PC 
compatibles. The NewWave environment supports all 
hardware peripherals supported by Microsoft Windows, 
including HP LaserJet printers, HP plotters, and the HP 
ScanJet image scanner. 

HP has developed an expanded memory card 2 for the 
HP Vectra ES Personal Computer that delivers substantial 
performance improvements without compromising the in- 
dustry-standard compatibility of the software using it. One 
of the objectives of this card is to enhance the performance 
of applications using Microsoft Windows, such as the New- 
Wave environment. 

The NewWave environment connects to networks using 
the HP AdvanceNet data communications software and 
hardware. Users have the choice of serial or HP ThinLAN 
or StarLAN connections to a local area network that may 
include other personal computers and an HP 3000 Com- 
puter system. Software developers can build distributed 
applications using the networking tools that HP provides, 
such as NetlPC interprocess communication software, the 
Cooperative Services library, and Resource Sharing. 

Conclusion 

The HP NewWave environment is an important step for 
HP in its strategy of giving computer users a powerful soft- 
ware environment that allows them easier access to infor- 
mation wherever it is stored on the computer network. For 
the first time we are able to produce a system built on a 
common architecture, rather than a collection of individual 
products. The NewWave environment that is available 
today is the beginning of a trend in software system design 
that will eventually give the benefits of NewWave to the 
entire spectrum of information workers. 

Reference 

1. I.J. Fuller, "Electronic Mail for the Interactive Office," Hewlett 
Packard Journal, Vol. 34, no. 2, February 1983. 

2. G.W. Lum, et al, "Expanded Memory for the HP Vectra ES 
Personal Computer," Hewlett-Packard Journal, December 1988, 
pp. 57-63. 
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An Object-Based User Interface for the 
HP NewWave Environment 

The NewWave environment is designed to allow users to 
focus on their tasks and not the tools. To accomplish this, 
the NewWave environment presents users with a 
conceptual model based on an office metaphor that is built 
on an object-based architecture. 



by Peter S. Showman 



A KEY ELEMENT OF THE HP NEWWAVE ENVIRON- 
MENT is the combination of a system conceptual 
model, which defines the user's perception of how 
the system works, and an object model, which defines the 
architecture of the system. This article describes the New- 
Wave conceptual model and object model by presenting 
examples based on an office metaphor. 

Matching Computers to People 

As the use of personal computers in business has become 
more and more widespread, two conflicting trends have 
emerged. The complexity of the systems and applications 
has increased dramatically. Computers are being applied 
to more complex and more strongly interrelated tasks, often 
requiring the use of several interacting application pro- 
grams and data from several sources. At the same time, the 
need for simple operation is critical. The typical PC user 
is no longer a computer hobbyist. Most users are busy 
enough maintaining expertise in their own areas without 
having to be computer experts as well. Software must be 
easy to learn and easy to use for first-time or occasional 
users without sacrificing flexibility and effectiveness for 
more experienced users. The conflict between the need for 



simple operation and the increasing functional complexity 
leads not only to less user satisfaction, but also to decreased 
productivity and increased training costs. 

A simple and consistent user interface has been a long- 
standing goal of many HP products, including such com- 
mercial and office products as the HP Touchscreen Com- 
puter, 1 HP DeskManager, 2 and the HP 250 Computer, 11 along 
with numerous earlier systems (e.g., reference 4). Applica- 
tion of human factors principles and ever-improving 
hardware have allowed designers to build interactive and 
responsive application programs. Such software keeps the 
user informed about the state of the software and the data, 
and reduces the prior knowledge required to operate it. 
Techniques that were once seen only on expensive work- 
stations are now commonplace in personal computers. 
However, in spite of clear progress, a number of obstacles 
remain for the users. 

Where We Are Today 

Today's office automation software is almost exclusively 
function-oriented. Most of the user's work is done in terms 
of the functions incorporated in the application programs 
the system provides. The first decision the user must make 
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Fig. 1 . A complex object and its 
components. Each of the compo- 
nent objects has associated with 
it an application and a data seg- 
ment containing the data it is cur- 
rently managing. 
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is, "Which application should I run?" Only after the appli- 
cation has been selected can the user indicate which data 
should be used, typically by remembering and typing in 
rather cryptic file names. If that data is not of the correct 
type for the application, the user is given an error message. 

Transferring data between systems or among the applica- 
tions within each system is a significant and yet difficult 
part of many common tasks. Often such data transfers must 
be done manually on a trial-and-error basis — even for re- 
petitive transfers. Where applications allow several data 
files to be tied together, the result still must be maintained 
manually (e.g., when copying compound items such as text 
and graphics, or sending them via electronic mail). Unless 
the user is very careful and understands the system well, 
it is easy for a mailed document to lose its figures acciden- 
tally, or for a spreadsheet that consolidates the results of other 
spreadsheets to become separated from its components. 

There are other annoyances as well. Many users must 
juggle several tasks at once, often changing from one to 
another as interruptions occur in the workplace. This is 
often difficult because MS-DOS®, the most common operat- 
ing system for personal computer systems, restricts the user 
to operating one application program at a time. Exiting one 
program to run another is time-consuming, and the problem 
of remembering and restoring the context on returning is 
typically left to the user. Although many application pro- 
grams have independently developed workable user inter- 
faces, until recently there has not been much standardiza- 
tion across applications within this environment. Thus, 
users must learn and remember how to direct each appli- 
cation to perform its various functions, and often opera- 
tions common to several applications are handled differ- 
ently by each. 

The net effect is that in the course of accomplishing the 
real task at hand, the user must also solve some additional 
problems introduced by the system: determining which of 
the available programs is appropriate for each step, remem- 
bering the names of the files that contain the data, and 
managing the movement of data between the programs. 
These problems have little to do with what the user really 
wants to accomplish — they are just extra things to worry 
about. 

Tasks, not Tools 

The NewWave environment is designed to address many 
of these problems. At the visual and operational level, it 
strongly encourages the basics of good software design, 
such as a consistent and logical user interface, the use of 
WYSIWYG (what you see is what you get) displays, and 
direct-manipulation interaction. Many of these characteris- 
tics are based on the features of Microsoft Windows, on 
which the current NewWave environment is built. The 
NewWave environment also inherits two very important 
features of Microsoft Windows: multitasking to allow more 
than one application program to be active simultaneously, 
and window management facilities so the user can switch 
among applications. 

The NewWave environment takes a step beyond the fea- 
tures of Microsoft Windows by providing an architecture 
for managing data and applications and a consistent con- 
ceptual model to help the user understand the system. 



Whereas most systems today are function-oriented, the 
NewWave environment is information-oriented. With the 
NewWave environment the user can operate in terms of 
the information stored in the system, and instead of decid- 
ing which application to run, the user's first decision be- 
comes "Which information do I want to work with?" The 
system will automatically pick the application that is 
appropriate for working with that kind of information. 

A phrase we have used to capture the overall goal of the 
NewWave evironment is "tasks, not tools." By this we mean 
that users should be able to focus primarily on what they 
want to accomplish (their tasks), and not have to spend so 
much mental energy on the mechanics of how to do it (the 
software tools). Put another way, the computer should be 
part of the solution, not part of the problem. 

The underlying NewWave architecture provides other 
benefits as well. Some of these, such as the task automation 
provided by the agent facility and the comprehensive help 
facility, are also directly beneficial to the user. Other 
characteristics, such as the ability of one application to use 
features of another, are primarily visible to application de- 
signers. However, they often benefit the user in the end. 
Several of these aspects of the NewWave environment are 
the subjects of other articles in this issue. Here, we will 
focus on how data and application programs are managed 
in the NewWave environment, and how these and other 
features of the system are presented to and managed by 
the user. In sum, these NewWave characteristics constitute 
a significant step forward in reducing the complexity from 
the user's viewpoint while simultaneously providing: 
I An information-oriented user interface that makes the 



NewWave Office 




Fig. 2. Simple links are parent-child relationships that attach 
the child to the parent with minimal obligations on the child. 
Visual links are used when a parent object requires the child 
object to display itself within the parent's window and print 
itself as the parent is printed Data passing links require data 
transfer between the linked objects. Visual and data passing 
links are also called views in OMF terminology. 
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process of running an application transparent. 
a Information storage and retrieval that allow the worksta- 
tion user to label, store, find, and manage information 
conveniently. 

■ Automated data integration among independent applica- 
tions, including multimedia compound documents (e.g., 
documents that contain text and other data types such 
as graphics). 

a Simple data interchange between systems, including ex- 
change of integrated data items between work groups 
connected by networks and electronic mail. 

Conceptual Models 

A key consideration throughout the NewWave develop- 
ment was how to present the system features so they would 
be easy to understand and remember. As users explore a 
system, they develop mental images or models of how the 
system works. As a simple example, a new user will quickly 
observe that when the mouse is moved on the table, a 
cursor on the screen moves correspondingly. Consistent, 
logical behavior helps the user build the correct model and 
then reinforces it, making it easy for the user to predict what 
will happen in other similar circumstances. However, even 
the slightest inconsistent behavior of the system tends to 
break down the models the user has constructed, often 
leading to frustration and confusion. 

To achieve this consistency, there should be a cohesive 
conceptual model of how things work. This model must 
be understood by the developers and presented clearly and 
consistently to the users. If there is a close enough match, 
patterning portions of a system's behavior after the real 
world by using visual and operational metaphors can help 
the behavior seem logical, or at least familiar — and hence 
more rememberable. 

Also, the apparent complexity of the system is directly 
related to the number of different concepts and rules 
needed to describe how things work. Thus, consistency is 
important not only in doing the same things the same way 
within the user interface, but also in treating similar things 
similarly in the fundamental behavior of the components 
of the system. As will be seen, an object management ar- 
chitecture, together with an object-oriented user interface, 
was chosen as the best way to provide a consistent approach 
to information management. 

The Object Model 

To show how an object model addresses these problems, 
we should first describe a few key characteristics of soft- 
ware objects. In general, a software object is a set of data, 
plus the software required to manage the data and provide 
access to it. An object can be small, such as a word or a 
number, in which case the associated software is relatively 
simple, or it can be more complex, such as an entire docu- 
ment (see Fig. 1). NewWave objects are typically complex, 
corresponding to the kinds of data ordinarily associated 
with traditional office application programs: complete 
documents, spreadsheets, charts, drawings, and so on. In 
essence, the software associated with a NewWave object 
is an application program corresponding to typical office 
applications. However, there are some key differences be- 
tween the way ordinary application programs and objects 



behave. 

The most noticeable characteristic of an object is that a 
user never needs to know what program actually manages 
the object. The user just asks to perform some operation 
on an object, such as to see it, edit it, or print it, by using 
standard commands. The object management facility 
(OMF), which keeps track of all NewWave objects, knows 
which application software is appropriate, and runs it auto- 
matically behind the scenes to do the work. This provides 
the information orientation needed to remove the extra 
step of selecting and running the correct application. The 
OMF is described in the article "The NewWave Object 
Management Facility" on page 17. 

Another key characteristic, not visible to the user, is that 
processes behind each object are designed to communicate 
with each other by sending and receiving messages. A stan- 
dard message protocol allows one object to negotiate with 
another object to find out what operations the other object 
supports (e.g., displaying, printing, or user editing), and 
also to request the object to perform any of the operations 
that it supports. This combination of negotiation plus ac- 
tion lets objects interact flexibly with each other in mean- 
ingful ways, providing an underlying mechanism for auto- 
mated data integration in the NewWave environment. In 
particular, it lets one object send information to or perform 
services for another object even though the objects may 
have been designed without knowledge of each other. For 
example, a chart object can get the data to be plotted from 
a spreadsheet object, or a document can ask a graphics 
object to display or print an illustration on its behalf. As 
will be seen, the user does see this communication flexibil- 
ity indirectly, in that objects can easily be connected in 
various combinations. 

Linking the Objects 

As noted above, the ability of objects to communicate 
with each other, requesting and providing services and 
information, provides a key form of data integration in the 
NewWave environment. But to communicate, the objects 
must somehow be connected to each other. To take advan- 
tage of the flexibility of the object model, the user should 
be able to manage these connections easily among objects 
that are ordinarily independent. In the NewWave environ- 
ment, these connections are accomplished by establishing 
persistent links between objects. The links are persistent 
in that they remain until explicitly broken, and like the 
object-to-application linkages, they also are maintained by 
the OMF. 
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Fig. 3. Categories of objects in the NewWave environment, 
with examples. 
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Although there are a number of ways links could be 
managed, a hierarchical structure of linked objects is used 
as the starting point for the NewWave environment. The 
NewWave Office, which is a special application that pro- 
vides access to the features of the NewWave environment, 
forms the top of the hierarchy, with other objects descend- 
ing from it (see Fig. 2). Within a pair of linked objects, the 
one that is closer to the top of the hierarchy is called the 
parent and the lower one is the child. In general, the set 
of all the objects below a given object might be called its 
descendants. The only structural restriction imposed by 
the OMF is that there can be no loops, in the sense that no 
object can be its own descendant. 

Links between objects may be used simply to keep the 
objects together; these are called simple Jinks. Links can 
also be used to let the child object provide data or services 
to the parent object; these are called data Jinks. Because a 
data link in effect allows the parent to view a portion of 
the child object, data links are also sometimes called views. 
These provide for automatic updating of one object by 



another, a facility sometimes referred to as a hot connect. 

The Office Metaphor 

Rather than requiring users to manipulate links directly, 
which would have required us to display hierarchy dia- 
grams such as that shown in Fig. 2, the NewWave Office 
provides an office metaphor for managing and using ob- 
jects. This metaphor is built around a containment model. 
In this model, an object is connected to its parent, and thus 
placed in the hierarchy, by putting it inside the parent 
object. To exist, an object must be attached to a parent — or 
in terms of the containment model, must be inside some- 
thing. The visual presentation reinforces this containment 
model. For example, a folder window contains and displays 
icons that represent the objects contained in the folder, 
and a WYSIWYG document contains visual representations 
of the contained figures. 

Objects in the NewWave Office fall into two primary 
categories: tools and user objects (see Fig. 3). Sometimes 
the latter are simply called objects. Note that the tools in 
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Fig. 4. Rife system in the New- 
Wave environment, (a) The file 
drawer contains the folder "Monthly 
Reports," whose contents can be 
displayed by opening it. (b) The 
folder "Monthly Reports" contains 
the report of interest. Note that 
icons are used to represent ob- 
jects within the file system. 
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Fig. 3 are singular because they are permanent parts of the 
system that cannot be duplicated, mailed, or destroyed by 
the user. However, they can be added or removed as part 
of system installation and maintenance, and it is sometimes 
possible to install two similar tools (e.g., two printers). User 
objects, on the other hand, can be freely created, copied, 
mailed and destroyed. The subcategories shown in Fig. 3 
are less well-defined than the major categories, but still 
prove useful for classifying similar objects' characteristics. 
Simple Tools and Simple Data Objects. Objects that nom- 
inally cannot contain other objects fall into these categories. 
However, some of the tools shown as simple can in fact 
hold objects temporarily while processing them (e.g.. the 
printer object temporarily holds objects being formatted 
for printing). 

Container Objects. The primary purpose of containers is 
to hold objects without actively using them. Since contain- 
ers make no demands on their contents, they usually can 
contain any sort of user object. For example, the file drawer 
can contain folders, and folders can contain documents, 
but neither container does anything with its respective con- 
tents. But again there are exceptions; the in tray can only 
contain envelopes, and the wastebasket acts on its contents 
by destroying them when the user empties it. 
Compound Data Objects. These are user objects that gener- 
ally have data of their own, but can also contain other 
objects for specific purposes, usually to supply data or 
provide display services. Because they do place particular 
demands on their contained objects, only certain combina- 
tions are meaningful and are allowed (e.g., a document 
containing a spreadsheet is a valid combination, but a 
spreadsheet containing a document is probably invalid). 
Because the objects can negotiate with each other, the user 
can be told immediately if an improper combination is 
proposed. 

Examples 

Let's consider three examples that illustrate the im- 
plementation of the hierarchical object model and the con- 
tainment model in the NewWave environment. The exam- 
ples illustrate information storage and two kinds of data 
integration. Although in other systems these situations 
have typically each been handled differently, they all fit 
well into the hierarchical object model by using links in 
three different ways. This common underlying implemen- 
tation makes it easy to provide a consistent user interface 
and conceptual model. 

Example 1 

In a single-user workstation a hierarchical filing system 
is a direct and natural way for the user to store things. The 
obvious metaphor is a file drawer containing several hang- 
ing folders, each possibly containing other folders and vari- 
ous data items. This can be represented directly by the 
hierarchical object structure, in which data objects are 
linked to (contained by) folder objects, which are linked 
(possibly through other folders) to the file drawer. Because 
no information passes between these objects, they can be 
connected by simple links. And because the folder displays 
no data from the contained objects, an object within a folder 
can be represented simply as an icon or a line of text, as 



in the NewWave Office (See Fig. 4). 

From any level, the user can manipulate a lower-level 
child object as a whole entity by manipulating the icon. 
Items can be moved from one folder to another, or out of 
the file drawer entirely, by moving the corresponding icon 
from one window to another. The user simply points at 
the icon using the mouse, presses a mouse button to pick 
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Fig. 5. The OMF provides the linkage between the information 
the user wants to update (text file JRDATA.DOC in this example) 
and the application (wordproc.exe,) associated with the 
data. Double-clicking on the icon within the folder "Monthly 
Reports" would cause the folder application to request the 
OMF to open the corresponding object. 
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up the icon, drags it to the new location, and releases the 
mouse button to let go. The OMF maintains the relation- 
ships between the file drawer, folders, and other objects 
contained in them based on changes made by the user. All 
the user needs to worry about is where the icons that rep- 
resent the objects are displayed. 

The user can also choose to open a contained object to 
operate on it in detail, by pointing at the icon and double- 
clicking (pressing the mouse button twice) as shown in 
Fig. 4. The OMF instructs the application program as- 
sociated with the object to run, and provides the name of 
the data file. The application program then creates a new 
window and displays the contents of the open object for 
the user to manipulate as desired (see Fig. 5). The represen- 



tation in the parent object is greyed to show it is open. 
When the user has finished, the window is closed, and the 
object is once again shown only in its parent folder. 

Example 2 

A compound document also provides a natural hierarchy 
in which the objects corresponding to the illustrations and 
tables contained by the document are all attached to it by 
a type of data link (view) called a visual link. These con- 
tained child objects are in fact responsible for displaying 
and printing the information contained in the correspond- 
ing illustrations and tables. Therefore, as in the first exam- 
ple, because the child object is linked to its own software, 
the user can double-click on the illustration to open the 




Fig. 6. The process of opening a 
figure object within a document 
and editing it is illustrated using 
some sample applications pro- 
vided to NewWave developers, (a) 
Each child object is attached to 
the parent (Layout object called 
Text and Shapes) by a visual link, 
(b) The child object's application 
(HP Shape) is responsible for dis- 
playing the object and providing 
the user interface, (c) and (d) See 
page 15. 
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corresponding child object, thus running the associated 
application, and make changes to the illustration using the 
application's user interface. This is illustrated in Fig. 6 
using two of the sample applications provided to NewWave 
developers, Layout and HP Shape. When the user closes 
the child object, the application associated with the child 
first updates the representation in the parent document 
automatically. 

Example 3 

In addition to being used to provide a service as in exam- 
ple 2, a data link can also allow data to be passed from 
one object to another for further processing. We call this a 
data passing link. A typical data passing scenario might 



have two spreadsheets linked together and passing data to 
a third, the consolidation sheet (see Fig. 7). This third 
spreadsheet combines the data, and is in turn linked into 
a chart, which displays some values from the consolidation 
spreadsheet graphically. Again, this can be described as a 
hierarchical set of linked objects. Here, in contrast to the 
document situation described in example 2, the child ob- 
jects actually pass data to the parent objects for further 
processing through a data passing link. The parent may 
use the data, which consists of numerical values in this 
example, in calculations or for plotting the chart. And the 
same access benefits apply here as well — the user can open 
the child from the parent, make changes to it, and have 
the changes reflected automatically back in the parent. Be- 
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cause the user starts from the initial representation of the 
data in the parent, it may not even seem like data transfer 
at all, but just the natural consequence of changing some- 
thing and seeing the result. 

In all these cases, objects can activate their applications 
automatically and perform standard services. Thus, the ap- 
plication (object) receiving the information — for example, 
the charting application — does not need to know anything 
specific about the other application program, or the file 
format it uses, or even the name of the file where the data 
is stored. Instead, it simply uses the appropriate standard- 
ized data interchange protocol. The immediate benefit to 
the user is that many more combinations of objects can be 
linked this way than would be possible in a traditional file- 
based scheme. 

Because the links are persistent, the user never needs to 
worry about whether the components of the compound 
objects will be there. The OMF ensures that each one will 
continue to exist and be accessible as long as some parent 
object has a link to it. And because the links are managed 
centrally by the OMF, the user can copy the entire structure 
or mail it to another workstation simply by copying or 
mailing the top-level object, which contains all the others. 
The OMF, together with the objects themselves, ensures 
that each component is copied and placed in its proper 
place in the new object. 
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Fig. 7. Two spreadsheets are passing data to a third, and 
the third, a consolidation sheet, is passing data to a charting 
program that displays the data graphically. These objects 
are linked together by the OMF using data passing links. 
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Fig. 8. The spreadsheet is shared between the document 
and the chart, ensuring that both show consistent data. All 
the objects are also shared into the folder "Project" to allow 
direct access to each. 



Sharing Objects 

In one important respect the NewWave environment ex- 
tends beyond the capabilities implied by the containment 
model. A single object in the real world can only be in one 
place at a time. If a user wishes to use the same figure in 
two related documents, or to file a document under multi- 
ple categories in a file drawer, multiple copies of the item 
must be used. In the NewWave environment, an object can 
be linked to more than one parent object — or in the New- 
Wave containment model, it can be contained in more than 
one place at a time. The user can control this by using the 
NewWave share command. On the surface share works like 
the Microsoft Windows copy command, in that the user sees 
the same data in the new location as in the old. The share 
command differs in that there is actually only one copy of 
the data. When changes are made to a shared object, the 
changes show up in all the locations that share the object. 
For example, the user may have a spreadsheet whose data 
is used to create a chart, and which is also displayed di- 
rectly in a document along with the chart (document in 
Fig. 8). The user can also share the items into a folder, for 
example to allow direct access to the spreadsheet without 
going through the chart (folder in Fig. 8). Any change to 
the spreadsheet, no matter how it is accessed, will automat- 
ically be reflected in the chart and the document. This 
greatly enhances the user's flexibility in managing the ob- 
jects and their connections. 

User Interface Specifications 

As noted earlier, the NewWave environment is designed 
to work within the Microsoft Windows environment. In 
addition to the architectural support features already men- 
tioned, Microsoft Windows defines a user interface style, 
described in an application designer's style guide. This 
style guide sets the standards for using many of Microsoft 
Windows' features, such as menus, dialog boxes, and the 
data transfer clipboard. 

The NewWave user interface specifications, described 
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for software developers in the NewWave User Interface 
Design Rules document, were developed as consistent ex- 
tensions to this basic definition. The share command de- 
scribed above is an example because it has many charac- 
teristics in common with the existing copy command, and 
it is presented to the user in the same way. Other areas in 
which the Microsoft Windows style guide was extended 
include a more fully specified set of editing and cursor- 
motion commands, a more comprehensive specification 
for dialog box use, and the requirement that applications 
provide user help in a consistent way. 

In a few areas there are conflicts, and the NewWave and 
Microsoft Windows standards differ. The use of an object 
model rather than the traditional applications and files 
model led to most of these differences. But the result is a 
standard that recognizes that users may need to use non- 
NewWave applications under Microsoft Windows concur- 
rently with using the NewWave environment. The standard 
attempts to minimize the differences. 

Conclusion 

The NewWave environment's object technology provides 
a powerful, flexible and extensible data integration and 
management tool, allowing new applications to become 
full participants in the NewWave family without requiring 
changes to any other NewWave applications. This informa- 
tion orientation provided the opportunity to simplify many 
aspects of the system's behavior, and to make the user 



interface more regular. Together with a consistent set of 
user interface design rules, these features truly allow New- 
Wave users to focus on their own tasks, rather than being 
distracted by system-imposed stumbling blocks. 
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The NewWave Object Management Facility 

An object-based file system is the foundation of the 
New Wave environment. This paper describes the concepts 
and features of this system. 

by John A. Dysart 



THE NEWWAVE OBJECT MANAGEMENT FACILITY 
(OMF) provides the HP NewWave environment with 
a sophisticated object-based file system. The objec- 
tives for OMF can be translated into the following features: 
3 Focus on tasks. Our initial designs of a user interface for 
the NewWave environment clearly indicated that an ob- 
ject model could help solve many problems. An object 
model allows a user to spend more time thinking about 
the task to be done and less about how to get the computer 
to do it. The OMF helps by providing a file system for 
storing objects. 
■ Compound multimedia objects. The OMF is needed to 
keep track of all the relationships between objects. This 
knowledge can be used to manage compound objects as 
an integrated whole. 
n Data sharing. OMF supports automatic data transfer so 



that new data can be entered in one place and then 
propagated to all the other places it is used. 

I Code sharing. OMF helps the application designer by 
making it easier to write and use reusable code. The 
NewWave environment uses this ability to provide many 
system services that can be plugged into applications. 

■ Evolution versus revolution. Use of the OMF does not 
require developing applications in a completely different 
way. Current development languages and tools can be 
used. OMF also runs on the current generation of 
hardware and software platforms. Most important, the 
basic OMF features scale very well into the more sophis- 
ticated development environments that may exist in the 
future. 
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OMF Concepts 

Objects and Classes 

A NewWave user uses objects for the storage of data. 
Examples of objects include folders, documents, spread- 
sheets, and charts. Each object is a set of data files joined 
with an application program that is capable of processing 
those files. Many different objects with different data files 
can be bound to the same application program. Objects 
that share an application program in this way are of the 
same class (see Fig. 1). 

New classes are installed into the OMF with an installa- 
tion script that is written by the application developer. 
This script contains all the information the OMF needs to 
create and use objects of the new class. A user only needs 
to know the name of the script file, and the rest of the 
process is automatic. 

There are two basic kinds of objects: global and user. 
Global objects are used to represent fixed entities in the 
system, such as a printer or wastebasket. Global objects 
are installed with the system and cannot be copied or de- 
stroyed by the user. Global objects can be referenced by 
any object in the system, and are often used to provide 
some common service to the other objects. Global objects 
that are visible to the user are called tools. User objects are 
objects created by the user to organize and contain data. 
User objects can be copied, moved, and destroyed by the 
user. 

Some object-based systems allow objects to be used at a 
very fine level of granularity — for example, a separate ob- 
ject for each character of a document. In the OMF design, 
we took a more pragmatic approach and decided that ob- 
jects should be used to represent larger entities, such as 
whole charts and reports. This approach allows applica- 
tions to be programmed more conventionally, and is less 
demanding of hardware and software resources. OMF pro- 
vides a very rich integration between these larger objects. 

The data files associated with an object are just ordinary 
files in the MS-DOS®' file system. The names of these files 
are generated automatically by the OMF and are not entered 
by or displayed to the user at any time. To optimize perfor- 
mance, the OMF automatically distributes the data files 
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among a number of internal subdirectories that are created 
and maintained for this purpose. 

All NewWave files, data and executables, are kept in 
MS-DOS directories separate from the user's other files. 
This allows the same storage volume to be used for other 
purposes, and makes it easier to archive and restore the 
NewWave portion of the file system. 

Properties 

Properties are chunks of data used to store descriptive 
information about objects and classes — for instance, the 
name of a class of objects, or the last time an object was 
modified. Fig. 2 illustrates some typical object and class 
properties. 

Each object has a list of properties associated with it. An 
application can read or write the data associated with a 
property by specifying the object and the name of the prop- 
erty. There is also a property list associated with each in- 
stalled class. The properties in a class property list are 
common to all objects of that class. 

Property names can either be strings, such as MyProperty, 
or numbers. Numeric names offer the advantage of being 
more efficient to access and store. 

A number of properties, such as the object title, have 
been standardized so that they can be used by all applica- 
tions. Some of these standard properties are listed below. 
The OMF also allows application developers to define their 
own private properties. 



PROP_TITLE 
PROP.COMMENTS 
PROP_CREATOR 
PROP_CREATED 



PROP_LASTWRITER 
PROP.MODIFIED 
PROP_CLASSNAME 
PROP_TEXTID 



Links 

A key feature of the OMF is the ability to link objects 
together into compound objects. A link is a directional 
relationship from one object (called the parent) to another 
object (called the child). All objects have at least one parent, 
and can have any number of children. The one restriction 
is that the OMF will not allow an object to become its own 
descendant. 

There are two kinds of links: simple and data. Simple 
links are usually used to support containment. For exam- 
ple, a folder object has a simple link to each object that it 
contains. Simple links are used to implement a hierarchical 
filing system, with the additional capability of supporting 
shared objects. Thus a single object can be contained in 
any number of folders, and be equally accessible from each. 
For example, a spreadsheet named "Western Division Sales 
Data" could be filed in a folder named "Western Data" and 
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also in another folder named "Sales Data." 

Data links, which are also called views, are a more sophis- 
ticated kind of link. Data links are just like simple links 
except that the child object can automatically transfer data 
to the parent object each time new data is available. If a 
view is simply displayed as an illustration in the parent 
object, the view is a visual view. For example, figures in 
a word processing object would be included using visual 
views. In a visual view, the parent does not get data from 
the child and then execute its own code to display the 
object, but simply tells the child to display the requested 
portion of the display. Alternatively, if data values are 
passed through the view, it is called a data passing view. 
For example, when a spreadsheet object gets data from 
another spreadsheet it is using a data passing view. Views 
are described in more detail later in this article. 

Since the OMF knows about all the links in the system, 
it can manipulate a compound object as a whole when it 
is copied, mailed, or destroyed. Users do not need to re- 
member and manipulate each component of the object 
separately. 

Each link has a reference name that is a number assigned 
by the parent object to the link to identify a particular 
child. Parent objects use these reference names in their 
own data files to refer to their children. The reason for this 
is apparent when you consider what happens when a com- 
pound object is copied. By default, when a parent object 
is copied, the descendants of the parent object are copied 
as well (see Fig. 3). The copy of the parent object will 
expect to use the same reference name to refer to the copy 
of the child object that the original parent used to refer to 
the original child. Reference names provide the indirection 
necessary to make this possible. It is possible to override 
this default behavior when parent objects are copied. If a 
child object has a property named PROP_PUBLIC, when one 
of its parents is copied, the copy of the parent will be given 
a link to the public child, rather than to a copy of the child 
(see Fig. 4). 

Messages and Methods 

The OMF allows objects to communicate with each other 
using messages. For example, parent objects use messages 
to cause their children to display or provide data. Most 
messages are defined to work with any kind of object, so 
applications are isolated from having to know exactly the 
kind of object receiving the message. This allows new kinds 
of objects to be integrated into the system without having 



to modify any existing applications. 

The code that an object executes when it receives a mes- 
sage is called a method. Saying that an object supports the 
X method simply means that it has code to process the X 
message. Sending a message to an object is similar to di- 
rectly calling the method code. The distinction is that the 
message is generic; it can be sent to any kind of object 
without changing the code in the sending application. But 
the actual code executed when the message is sent is differ- 
ent depending on what kind of object receives the message. 
For example, when a message to print is sent to a word 
processing object the word processor code for printing a 
document is executed. And if that very same message is 
sent to a spreadsheet object, the spreadsheet application 
code for printing a spreadsheet is executed. 

Applications send messages by calling the function OMF_ 
Send. The sender specifies the reference name of the desti- 
nation object, the message type, and any additional param- 
eters the message may have. The OMF directs the message 
to the appropriate object, which receives the message as a 
Microsoft* Windows message. The receiver performs the 
requested function and returns a status value. The OMF 
then returns this status value as the return value of OMF_ 
Send. This process makes messages synchronous, meaning 
that the sender does not proceed until the destination has 
processed the request (see Fig. 5). 

Life Cycle of An Object 

There are six stages in the life of an object. Fig. 6 shows 
how an object moves between these stages in its life cycle. 
The stages are: 

■ Creation. Objects are often created by copying a template 
object of the desired type. Objects are also created when 
they are received as data in an electronic mail message, 
or when a temporary object is created to perform some 
task. The object that calls the OMF to create the new 
object becomes that object's parent. 

■ Activation. An object is activated whenever some other 
object tells the OMF that it wants to send a message to 
it. The OMF starts a new process running the object's 
application, and passes to it the names of the object's 
data files. While active, an object generally is in a loop, 
receiving and processing messages sent from Microsoft 
Windows, the OMF, other objects, and other sources. 

s Opening. Activation of an object is invisible to a user. 
However, when a user wants to edit an object, that object 
needs to present an interactive interface to the user. This 
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is called opening. Generally, a parent object is responsi- 
ble for providing a command in its user interface to open 
each of its children. When the user gives this command, 
the parent tells the OMF to activate the child, and then 
sends an Open message to it. When the child receives the 
Open message it presents its user interface on the display 
screen, and becomes interactive with the user. 

I Closing. When the user finishes editing an object, the 
object's user interface is given a Close command. The 
object tells the OMF that it is closing, and then removes 
its user interface from the display screen. 

■ Termination. An object remains active as long as it is 
open or is being held active by some other object. The 
OMF terminates an object as soon as both of these con- 
ditions become false. OMF sends the object a Terminate 
message which lets the object save to disc any state in- 
formation it has in RAM. Then the OMF terminates the 
process that was started when the object was activated. 

« Destruction. When an object only has one parent and 
that parent deletes its link to the object, the OMF destroys 
the object. Destruction reclaims all the disc space that 
was allocated to the object's data files and properties. 

OMF Views 

Perhaps the single most important feature of the OMF is 
the support of automatic data transfer through the use of 
views. A view is a special kind of link for data transfer 
from the child object to the parent. Each time the child is 
changed, any parent objects that depend on the linked data 
are automatically updated. Each view has associated with 
it a destination specification, a source specification, a data 
ID, a view class, and an optional snapshot object. 

Destination Specification 

The destination specification is a data structure that is 
maintained by the parent object to keep track of how it is 
using the linked data from the child. For example, for each 
figure in a word processing object there is a destination 
specification that provides information such as where in 
the document the figure appears and how large it is. Usu- 
ally, the parent also keeps the reference name of the view 
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in the destination specification so that it can map from the 
reference name to information about how the view is used. 
The OMF does nothing to maintain destination specifica- 
tions. 

Source Specification 

The source specification is a data structure that is main- 
tained by the child object to keep track of a part of itself 
that is being transferred through a view. For example, when 
two spreadsheets are linked together, the child maintains 
a source specification that tells it what range of its cells 
are linked to a parent. Like destination specifications, the 
OMF does nothing to maintain source specifications. 

Data ID 

The data ID is a number that the child object gives the 
OMF to identify a particular range of linked data. The child 
object must be able to map from a data ID to a source 
specification, and vice versa. A number of different views 
from different parents may all share the same data ID and 
source specification if they all use the same range of linked 
data. 

The OMF keeps track of which data ID is associated with 
each view in a data structure called the OMF view specifi- 
cation. This allows the parent and child object to converse 
in the terms that are most natural for them, with the OMF 
providing the translation between them. For example, 
when any linked data is changed by the user, the child 
object tells the OMF the data ID of the changed data. The 
OMF then finds all of the parents with views of the child 
associated with the data ID of the changed data. The OMF 
notifies each of these parents of the change by sending 
them a DATA_CHANGE message containing the reference 
name of the view as a parameter. Fig. 7 illustrates the re- 
lationship between destination specifications, source speci- 
fications, and data IDs. 




Fig. 5. Control How of OMF_Send. 



Fig. 6. Life cycle of an object. 
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View Classes, Methods, and Messages 

Each view has a view class associated with it which is 
specified by the child object when the view is initialized. 
The view class determines the kinds of data transfer oper- 
ations the parent object can request the view to perform. 
Each of these operations is called a view method and the 
parent requests them by sending a view message to the 
view. 

If a child object supports the same set of view methods 
for all ranges of linked data, it only needs to use a single 
view class. An example of an object that needs more than 
one view class is a data analysis tool that can show both 
tabular and graphical representations of data. When a range 
of tabular data in this object is linked, a view class that 
supports transfer of data as text strings is used. However 
when graphical data is linked, the object uses a view class 
that supports transfer of data as a vector list. 

View classes, view methods, and view messages are anal- 
ogous to the classes, methods, and messages that were de- 
scribed earlier in this article, but are not exactly the same. 
The parent object uses different OMF functions to activate 
and send messages to a view than to activate and send 
messages to the child object of the view. The messages may 
ultimately be routed to the child, but they may instead be 
routed to a different object called a snapshot. Snapshots 
are described below. The indirection provided by view 
messages allows the presence or absence of a snapshot to 
be hidden from the parent object. 

Snapshots 

A snapshot is an object that serves as an intelligent buf- 
fer that allows the linked data from a child object to be 
accessed without activating the child. This results in better 
performance and use of resources. When a view is ini- 
tialized, the child object tells the OMF whether or not to 
create a snapshot for the view, and if so, what kind of 
snapshot is desired. The child object then sends messages 
containing the linked data information to the snapshot. 
When the parent object sends a view message to the view, 
the OMF routes the message to the snapshot. The child 
object remains inactive. Fig. 8 illustrates how a snapshot 
is associated with a view. 

One reason why snapshots can improve performance is 
that they are implemented differently from normal objects. 
Normal objects have applications associated with them, 
but snapshots have dynamic libraries associated with them. 
Like an application, a dynamic library is a separate execut- 
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able file. It can be loaded and linked to while the system 
is running and unloaded when it is no longer needed. When 
a dynamic library is used to implement a snapshot, one 
procedure in the library is designated the message proce- 
dure. Each time a message is sent to the snapshot, the OMF 
calls the snapshot's message procedure. The message pro- 
cedure determines the type of the message and processes 
it accordingly. 

Unlike an application, there is no process or task as- 
sociated with a dynamic library; its code only executes 
when it is called from an application. Dynamic libraries 
do not require that a stack be allocated for them because 
they always use the stack of the application calling them. 
In addition, since sending a message results in a call to the 
message procedure in the library, the overhead of a task 
switch through the operating system is avoided. 

A second reason why snapshots can improve perfor- 
mance is that they only need to manage the data that is 
linked through the view. This data may be a subset of the 
child object's full data set (e.g., a small range of cells from 
a large spreadsheet), or it can be in a simpler form (e.g., 
just values instead of formulas). 

There is some additional overhead associated with a 
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snapshot. Each time the linked data is changed in the child 
object, the child must pass the new data to the snapshot 
before the snapshot can supply that data to a parent. Snap- 
shots also take up additional disc space. Each application 
designer must carefully consider whether using snapshots 
will improve the performance of a particular application. 

Routing View Messages 

When a message is sent to a view, the OMF considers a 
number of factors in determining where the message should 
be routed. These include: 

■ Is there a snapshot? 

■ Can the snapshot handle this message? 

■ Is the snapshot's data up-to-date? 

■ Has the child object elected to process all messages? 
The flowchart in Fig. 9 illustrates how the OMF considers 

these factors when routing a view message. 

Other OMF Functions 

The OMF provides a number of other functions to appli- 
cation developers, including event notification, clipboard 
support, serialization, and start-up and shutdown control. 
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Event Notification 

Objects can tell the OMF that they wish to be notified 
when some specific event occurs. OMF provides this notifi- 
cation by sending a message to the object. The following 
notifications are possible: 

■ A property change message is sent when an object's own 
properties or the properties of one of its children are 
changed. For example, it is necessary to notify all open 
folders containing a shared object when the title of the 
shared object is changed. 

■ A child opening or closing message is sent when a child 
of an object is opened or closed. It provides visual feed- 
back concerning which object is being opened or closed. 

■ A copy or destroy message is used when an object is 
copied or destroyed. 

■ A configuration change message is sent when some sys- 
tem-wide configuration value is changed. 

■ A shutdown message is sent whenever the user tries to 
exit the NewWave environment. 

Clipboard Support 

Microsoft Windows provides a clipboard for data transfer 
which can hold any data that is in memory. The OMF 
enhances this clipboard by providing an invisible global 
object called the OMF clipboard. This global object serves 
as a temporary parent for any objects that are placed on 
the Windows clipboard. A temporary parent is needed so 
the object on the clipboard will have at least one parent 
and will not be destroyed while it is on the clipboard. 

The OMF also provides a facility for storing large 
amounts of data, that is, more than can fit into memory, 
in temporary files that are known to belong to the clipboard. 
OMF can then take care of deleting these temporary files 
when the clipboard is cleared or used for some other pur- 
pose. 

OMF provides functions that applications can call to put 
objects on the clipboard, remove them from the clipboard, 
and empty the clipboard. 

Serialization 

The OMF provides the ability to serialize compound ob- 
jects. Serialization takes an object that may have many data 
files, plus its descendents and their data files, and packages 
all this data into a monolithic stream of data called a serial 
file. This serial file can be easily copied onto a flexible 
disc or transmitted through the mail network. On another 
NewWave system, the serial file can be deserialized. This 
process unpackages all of the objects and data in the file 
and produces a compound object that is a copy of the 
original object. 

In general, the OMF can handle the serialization and 
deserialization of objects without any help from the objects 
themselves. However, in certain cases, objects may want 
to transform their data in some way when it is being copied 
to a serial file. If an object being serialized supports a 
method called SERIALIZE, the OMF will activate the object 
and send it a SERIALIZE message, rather than serialize the 
object's data files itself. The object then copies its trans- 
formed data into the serial file using an OMF function. 
When the resulting serial file is deserialized, the OMF 
creates a new object of the appropriate class, activates it, 



22 HEWLETT-PACKARD JOURNAL AUGUST 1989 



and sends it a DESERIALIZE message. The object reads the 
transformed data from the serial file using an OMF func- 
tion, and creates its normal data files. 

Start-up and Shutdown 

The OMF is the first process started when the user runs 
the NewWave environment. The OMF locates and opens 
the system files, which are a data base of all the classes, 
objects, links, properties, and so on. Once it has initialized 
itself, the NewWave environment activates and opens a 
special global object called the NewWave Office. The New- 
Wave Office provides a user interface for much of the 
OMF's functionality. See the following article, "The New- 
Wave Office," for more detail. The OMF itself is never 
visible to a user of the NewWave environment. 

When the user closes the NewWave Office, a function 
in the OMF is called to shut the system down. Any objects 
that are active when the system is shut down can request 
that the OMF restart them when the system is restarted. 
The next time the OMF is started, it will activate and open 
those objects after activating and opening the NewWave 
Office. The benefit of this to the user is that the NewWave 



environment can be exited and reentered without losing 
track of current status. 

Conclusion 

The NewWave OMF provides the foundation of the New- 
Wave environment. It implements a sophisticated object- 
based file system that can be accessed by any NewWave 
application. The OMF supports a powerful mechanism for 
building compound, multimedia objects with automatic 
transfer of data when changes are made. Although it does 
not have any user interface itself, it is in some ways the 
most important part of the NewWave user interface. 
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The NewWave Office 

The NewWave Office is the user interface for the NewWave 
environment. It provides the tools and methods to perform 
tasks found in a regular office environment. 

by Beatrice Lam, Scott A. Hanson, and Anthony J. Day 



THE NEWWAVE OFFICE IS THE FOCAL POINT for 
the user's interaction with the NewWave environ- 
ment, and it is the first NewWave object the user 
sees when the NewWave environment is initialized. It re- 
mains active throughout the entire session until the user 
terminates the NewWave environment. It incorporates 
many special features to reinforce the office concept in the 
minds of users. These features include iconic representa- 
tion of tools found in a real office, such as a file drawer, a 
wastepaper basket, a printer, and so on (see Fig. 1). The 
diagnostic tool shown in Fig. 1 is not a typical tool found 
in an office, but is a tool that enables NewWave application 
developers to interface to the NewWave object management 
facility (OMF). 

It is easy to work with these tools using a mouse to 
manipulate the icons that represent the tools. The tools are 
NewWave objects, as explained in the article on page 9. 
The user can either open the tool and move other NewWave 
objects directly into the opened tool window, or drop other 
objects on the icon representing the tool. Incoming objects 
are handled by each tool according to the function of the 
tool. The file drawer and the wastebasket accept the incom- 



ing object and display its representation in their windows. 
The printer, on the other hand, asks the object to print 
itself on the selected printer device. The diagnostic tool 
accepts an incoming object into its window and displays 
the OMF information pertaining to that object. In addition 
to viewing objects as icons, the user has the option to switch 
into the list view. In the list view, the title, type, and modi- 
fied date are displayed, and the objects are sorted by one 
of these parameters (see Fig. 2). 

This article describes the main features of the NewWave 
Office and shows how these features interact with the other 
NewWave components shown in Fig. 3. 

NewWave Windows 

The window that represents the NewWave Office is de- 
signed to remain as a background window while NewWave 
objects are open as pop-up windows over it. Activating an 
object window brings it to the top, overlapping other win- 
dows on the display (see Fig. 4). Since the office tools are 
always available, the user can easily manipulate an object 
from its window onto a tool at any time (e.g., moving a 
document to the wastebasket from a folder's window). 
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Another distinct feature of the Office window is its 
maximized window. When the NewWave Office window 
is maximized, all object windows remain in the same po- 
sitions while the Office window occupies the full screen 
in the background. When an object window is maximized, 
the object is brought to full screen and all other windows 
fall behind. The Office window can also be minimized; 
this hides all object windows and turns the whole New- 
Wave Office into an icon. 

To achieve these special display features, the NewWave 
Office uses functions from the library HPNWLIB.EXE. These 
functions are: 

D NW_CreateWindow. This function creates an object's main 
window and binds the object window as a child to the 
NewWave Office window. 

s NW_Minimize and NW_Maximize. These functions perform 
the window maximize and minimize operations de- 
scribed above. 

■ NW_Restore. This function returns a window from a 
maximized or minimized state to its original size. 
The default windows for the file drawer, the wastebasket, 
and folders are positioned in the NewWave Office window 
as shown in Fig. 4. The first window is positioned about 
halfway down the screen and partway in from the left, and 
the rest are staggered down and to the right of the other 
default windows. By using a defined parameter to the 
NW_CreateWindow function, NewWave applications can 
create default windows for themselves. 

Container Objects 

The NewWave Office is used as a temporary work space 
to store objects the user is currently working on. The file 
drawer and folders provide the NewWave user with a con- 
venient hierarchical filing and retrieval system to manage 
information. The wastebasket is used for discarding objects 
the user no longer needs, and a user-defined maximum 
number of objects can be set to trigger automatic emptying 
of the wastebasket when it opens. These four objects are 




Fig. 1. NewWave Office window. 



called container objects because they are capable of con- 
taining other objects (e.g., the file drawer contains folders 
and folders contain documents, and so on). These objects 
display and manage their child objects in identical ways. 
The menu for each of these object types is customized to 
the particular needs of that object. For instance, the waste- 
basket's Edit menu has the Delete command, whereas all 
other object types use the Throw Away command. 

The NewWave Office, the file drawer, the wastebasket, 
and folders share the same executable code. Every invoca- 
tion of the same code is an instance, a feature provided by 
the Microsoft"* Windows environment. For efficiency, only 
a single copy of the code is in memory, even though there 
are multiple instances running. The code is made up of 
multiple code segments, and only those segments in use 
are kept in memory. As other segments are needed, they 
are read in from disc. Each instance has its own data seg- 
ment, which includes global variables, the stack, and a 
local heap. 

When the first instance of the NewWave Office starts up, 
it computes certain environment variables and stores the 
results into some global variables. Also, several text fonts, 
paintbrushes, cursors, and other items are created and 
stored. Each succeeding instance needs to use these same 
items, and so copies them to its own data segment at start- 
up time instead of recomputing and recreating them itself. 

When the user runs another instance from the NewWave 
Office, such as the file drawer or folder, that object must 
open up to the same state it was in when last closed. This 
includes the object's window size and position, whether 
it was in iconic view or list view, where the window was 
scrolled to, and more. To do this, most of the needed infor- 
mation is kept in a data file associated with the object. The 
information is read from the data file and placed in the 
appropriate global variables for use when creating and dis- 
playing the instance's window. 

The container must also determine the list of children 
contained within it (e.g., the list of folders in the file 
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drawer). This information is also kept in the data file and 
is read in and placed in data structures in globally allocated 
memory. The children information, which is kept in the 
data file, is not always up to date. While the container was 
closed, new children may have been added, titles may have 
changed, children may have been opened or closed, and 
so on. The first situation might have occurred as a result 
of the OMF J\ddChildTo function (discussed on page 30), and 
the latter two would have occurred because the container 
is shared with other objects. To ensure that the data in the 
data file is correct when the child object is opened, the 
latest list of children that belong to the container, and in- 
formation about them, are obtained from the OMF. The 
information given by the OMF always overrides the data 
file, and when a container is opened a check is made with 
the OMF before finalizing the data structure. The OMF 
function OMF_EnumChildren is used to enumerate a con- 
tainer's children and to obtain the information to update 
its data structure. During enumeration, the OMF sends the 
container ENUMJDBJECT messages for each child belonging 
to it. In processing the message, if the child is not in the 
data file, it is added to the data structure. For new child 
objects, the information obtained from the OMF includes 
the object's title, its icon handle,* its active state, and the 
date and time when the object was last opened. All of this 
information is added to the data structure. 

To optimize enumeration, an object property called 
PROP_FASTPROPS allows retrieval of numerous pieces of 
information about an object in only one reading. PROP_ 
FASTPROPS includes the last-modified date, the last writer 
name, tool display information (PROP_SYSTEM described 
below), and the object's title string. 

The NewWave Office must also enumerate all of the tools. 
This is accomplished through the OMF function OMF_ 
EnumGlobalObjects. As with the data objects, the tools that 

"A handle is a pointer into a table ol pointers. The pointers in the table point to data or 
code segments scattered throughout memory that are allocated to the object that owns 
the handle Thus, the ob|ect's icon handle points to the location In the table (handle table) 
that points to the memory location where the object's icon is stored. 



are visible in the NewWave Office are added into the data 
structure using the information in PROP_FASTPROPS. Using 
the Manage Tools dialog box, which is available from the 
Settings menu item, the user can select which tools to display 
in the NewWave Office window and which are to be hid- 
den. This status is stored in the object's PROP_SYSTEM prop- 
erty: 0 means never display it (e.g., the OMF clipboard), 
1 means don't display it now, and 2 means display it. If 
the tool is never to be displayed and is in the data file, it 
is removed from the data structure. There is no need to 
waste space storing information on an object that is not 
displayed. 

The data structure that holds all this information is com- 
posed of two parts. The first part is an array of structures, 
one for each child in the container. This child array holds 
the OMF object name for each child, its location in the 
container, a flags word that indicates whether the object 
is selected or opened and other status, the pixel width of 
its title on the screen, the handle to the object's icon, the 
date and time of its last change, and indexes to its title and 
class strings. The second part of the data structure is the 
string lists. They hold the title and class strings for each 
object. The strings are stored end-to-end and each is pre- 
ceded by a length word and terminated by a NULL byte. 
This minimizes the overhead needed per string. These 
strings can be accessed quickly because each child's struc- 
ture in the child array contains offsets into these string 
lists for its title and class strings. One optimization per- 
formed is not to store duplicate strings in the class string 
list. If a newly added object's class string is already in the 
list, the object's child array structure references the one 
already in the list. This works out well because a container 
will usually contain many similar objects, that is, objects 
of the same class. 

Office Functions 

The NewWave Office not only provides the central user 
interface for object management, but also works in conjunc- 
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tion with the OMF to provide essential architectural com- 
ponents for the interaction with NewWave applications. 
The close cooperation between the NewWave Office and 
the OMF is achieved with the use of various OMF function 
calls, and the interaction with NewWave objects is done 
using predefined OMF methods. A few examples of these 
special interactions will be given in the following sections. 

The Create Process 

The user will frequently want to create a new object, 
which may be in the form of a new document, a new spread- 
sheet, a new pie chart, a new data base query result table, 
or some other typical office object. There were two require- 
ments for the user interface that displays the object types 
available to be created. 

■ The interface had to allow the user to invoke object cre- 
ation facilities from the NewWave Office window and 
from tools such as the file drawer, from containers such 
as folders, and from compound data objects such as a 
compound document. 



■ The interface had to show the user only those objects 
that can be created in the domain in which the user is 
working. For example, when the create process is in- 
voked inside a compound document object, a folder ob- 
ject cannot be created. 

The OMF maintains a list of all types of objects in the 
user's NewWave environment. This list represents a set of 
empty template objects and class information such as 
which methods a class of objects supports. Object templates 
are objects that are frequently used (e.g., form letters, ex- 
pense reports, distribution lists, etc.). To manage these 
template objects from within the NewWave Office and 
other objects, and to provide the features mentioned above, 
a tool called the creator was developed. The creator is a 
global NewWave object of type tool. Its object creation 
facilities are made available to the user by selection of the 
Create a New... command in the Objects menu. 

The creator has the only reference to all the template 
data objects installed in a NewWave environment. The 
creator's global OMF reference name is known throughout 
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the system and any application can establish communica- 
tion with it by simply specifying that reference name. De- 
veloping the creator as a distinct NewWave object provides 
all of the benefits of objects in the NewWave environment. 
Its protocol is defined and established so that other objects 
can communicate with it. The process of creating a new 
object is simply a matter of copying the template object 
and ensuring that the parent object, from which the user 
created the new object, establishes an OMF reference to it. 
CREATE_A_NEW Message. Communication with the creator 
to create a new object is accomplished with the CREATE _A_ 
NEW message. All container type NewWave objects are re- 
quired to provide the menu item Create a New..., which is 
used to set into motion the process of creating a new object 
(see Fig. 5). When the user selects Create a New... the object 
invokes the creator using the OMF_GetOMFObject call and 
sends it a CREATE_A_NEW message. It then terminates con- 
versation with the creator by calling OMF_FreeOMFObject. 
Sometime after terminating conversation with the creator 
the object may receive an OMF_NEW_OBJECT message con- 
taining the newly created object. If the user cancels dialog 
with the creator, this message may never be received. To 
prevent problems with reentrancy while waiting for the 
new object, the creator disables the caller's window. This 
prevents the user from doing anything else in that window 
until business with the creator is finished. 

The CREATE_A_NEW message may be accompanied by a 
memory handle to some global shared memory containing 
a list of methods the calling object requires its children to 
support. When the creator receives the CREATE_A_NEW mes- 
sage, it displays to the user a dialog box containing the 
icons and titles of all template objects that support the list 
of methods sent (see Fig. 6). If a methods list is not sent, 
it is assumed that all template objects are suitable and they 
are all displayed. The user is then able to choose an object 
to create and give it a title. 

When the user has chosen an object to create, given it a 
title, and hit the OK button, the creator calls an OMF routine 



to make a copy of the template object. The creator has a 
temporary reference to this new object. It uses this tempo- 
rary reference to write the user-supplied title to the new 
object's PROP_TITLE property. It also writes other properties 
of the new object such as PROP_CREATED, which is the time 
and date of creation, and PROP_CREATOR, which is the 
user's logon name. The creator then sends the calling object 
(the parent) an OMF_NEW_OBJECT message that has a refer- 
ence to the new object as a parameter. The calling object 
is expected to absorb the new object into its data structure 
and establish its own permanent OMF reference name to 
it. When control returns to the creator from this message, 
the creator deletes its reference to the new object, severing 
any further connection with it. If, for some reason, the 
calling object does not establish a permanent reference to 
the new object, the OMF detects that the new object has 
no references to it from any object and destroys it. 
Installing Objects. Since the creator is used to create new 
objects in the NewWave Office, it is also part of the process 
of installing new applications into the NewWave environ- 
ment. To install an object (i.e., an application) into the 
NewWave environment the user must provide the follow- 
ing files: 

■ An appropriate .EXE program file 

■ Default data files 

■ A help file 

■ An icon file in standard MS Windows format 

■ Any other necessary files, such as configuration informa- 
tion 

>d An installation file. 

The installation file, which normally has the extension 
.INS, is a command file that specifies everything the system 
needs to know about the object being installed. Entries 
include the class name, which defines the type of object, 
paths to the files on the installation disc, instructions de- 
fining where those files should be placed in the system, 
methods supported by the object, and other installation 
data. The installation file format is very flexible — for exam- 
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pie, it is possible to install compound objects and provide 
updates for installed applications with or without altering 
existing objects of that class. It is also possible to install 
global tool objects such as the wastebasket, the printer, and 
the creator itself. Tools cannot be created by the user; there- 
fore, they can only be added to the system by installation. 

The installation process is designed to execute with min- 
imal participation on the part of the user. It is possible for 
a user to install a complete NewWave environment merely 
by inserting the NewWave disc and running the NewWave 
install utility. The install utility creates a file called HPIN- 
STAL.IN$ in the NewWave system directory on the hard 
disc. This file contains a list of paths to one or more .IN$ 
files on the installation disc. After copying some system 
files onto the NewWave system directory, the install utility 
starts up the NewWave environment by running the OMF. 

The OMF is the first process to run at the start of a 
NewWave session. After performing some housekeeping 
chores, the OMF starts the NewWave Office. During its 
initialization phase, the NewWave Office looks for the 
HPINSTALINS file. If it finds one, it invokes the creator, 
passing the paths of the .IN$ files to it one at a time. The 
creator calls certain OMF routines to install the application 
and establish a reference to each new template object as it 
is built. At the end of this process, the creator, having 
successfully added these new children to its list, is termi- 
nated and the NewWave Office opens and presents its in- 
terface to the user for the start of the NewWave session. 
MS-DOS 1 * Objects. A major benefit of the NewWave envi- 
ronment is its ability to make objects from the data files of 
standard MS-DOS applications that were not written to run 
under the NewWave environment. This capability is known 
as encapsulation of MS-DOS applications (see article on 
page 57). Once an MS-DOS application is encapsulated, the 
user can create NewWave objects that represent data files 
pertaining to that application. These objects are known as 
MS-DOS objects. They can be displayed in the NewWave 
Office window the same as other objects such as the file 



drawer or folders. They appear as icons and can be manipu- 
lated by the user in the same way as true NewWave ob- 
jects. When the user opens one of these objects, a shell is 
run, which then runs the appropriate MS-DOS application 
and associates it with the appropriate encapsulated data 
files. 

Encapsulated MS-DOS applications are installed in 
much the same manner as regular NewWave objects. Be- 
sides the information provided in a typical NewWave in- 
stallation file, an MS-DOS installation file contains infor- 
mation such as keystroke sequences used by an MS-DOS 
application to load the encapsulated data files. 

MS-DOS objects that support the calling object's required 
methods appear in the creator's dialog box along with reg- 
ular NewWave objects. If the user chooses to create an 
MS-DOS object, the MS-DOS filename associated with the 
new object must be provided. The MS-DOS object is then 
created and special object properties are written to the 
object's data files. When the user first opens this MS-DOS 
object, the MS-DOS application shell reads these properties 
to find out what data files to load with the application. 

Masters 

Once the decision was made to make the creator a New- 
Wave object with the capability of managing other New- 
Wave objects, a very useful feature quickly presented itself. 
This is the ability of the user to create template objects 
from existing NewWave objects. These user-created tem- 
plates, or masters, can easily be sent to the creator which 
displays them and allows the user to create a new master 
in addition to new empty template objects. For example, 
the user can create a master from a form letter or spread- 
sheet using existing templates of the letter or spreadsheet. 
Adding Masters. The Save As Master... command, which is 
used to save master templates, is currently implemented 
in the NewWave Office, the file drawer, and in folder ob- 
jects. To save a master, the user selects an object icon in 
one of these window's objects and then chooses the Save 
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As Master... command from the menu. The container object 
then makes a copy of the selected object, invokes the 
creator, as described above, and sends it an OMFJNSERT 
message with a reference to the copied object as a param- 
eter. When the creator acknowledges the OMFJNSERT mes- 
sage, the container deletes its reference to the copied object. 
The original selected object is unaffected by this transac- 
tion. Objects saved as masters can be as complex as the 
user wishes. 

Upon receiving the OMFJNSERT message, the creator ver- 
ifies that the inserted object is an installed data object. It 
does this by comparing the object's class name with the 
class name of each of its empty template children. If the 
inserted object does not match any of the creator's children 
an error is signaled to the user. This can occur, for example, 
if the user tries to save as a master an object that was 
received through the mail, but is not currently installed 
anywhere on the system. 

When the master is accepted by the creator, an OMF 
reference name is established for it and it is placed in the 
creator's data structure. Whenever the user chooses the 
Create a New... command and selects a template object icon 
in the creator's dialog box, all masters associated with that 
template object are displayed in a Microsoft Windows 
listbox within the creator's dialog box. The user can then 
choose to create an empty template or a customized master. 
Managing the Masters. With the user given the ability to 
install template objects and save customized masters num- 
bering in the thousands, it became apparent that the user 
must be provided with a way to manage all of these objects. 
For example, the user should be provided with a means to 
put the most frequently created template objects at the front 
of the creator's display. This would eliminate the need to 
scroll the window to find the objects. In addition, having 
saved customized masters as templates, the user might de- 



cide to remove these masters from the creator's display. 
To solve these problems, a menu choice called Manage Mas- 
ters was added to the NewWave Office window. When this 
menu item is selected, the NewWave Office invokes the 
creator and sends it a MANAGEJvtASTERS message. The 
creator then displays the appropriate dialog box and waits 
for the user to decide what to do with the template and 
masters displayed. This dialog box allows the user to select 
a template object and change its position within the dis- 
play. It also allows the user to select customized masters 
in the listbox and press a Delete button which causes the 
creator to remove its OMF reference to that object. 

Opening an Object 

When the user opens an object, the NewWave Office 
must first find out whether that object class supports the 
open method by calling the OMF function OMF_GetMethod. 
If the method is supported, then the object is activated 
through an OMF call and the OPEN message is sent. Once 
the object is activated, other messages can also be sent. 
The telescoping effect is one example of the cooperation 
between the NewWave Office and the object. The telescop- 
ing effect is the drawing of a series of rectangle corners to 
simulate the enlargement of an object from a small icon to 
a full window. While processing the OPEN message, the 
object decides where its window should be opened, and 
sends back that coordinate through the OMF function OMF_ 
Opening. When the NewWave Office receives the informa- 
tion from the OMF, it uses the position of the object's icon 
in its window as the origin, and performs the telescoping 
effect using the OMF's library function call NW_Telescope- 
Effect. 

After the telescoping effect is performed, the object's 
iconic representation in the Office window is grayed out 
to indicate to the user that the icon is temporarily inactive, 
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and that all interaction with that object should be directed 
to its opened window. 

Attributes Dialog Box 

The attributes dialog box displays the generic properties 
of the object selected (see Fig. 7). It provides the user with 
more details about the object than are provided by the 
iconic view or the list view. The contents of the attributes 
box may be useful while the user is working within an 
object as well. The attributes dialog box is available to 
NewWave applications through the functions NWJDisplay- 
Attributes and NW_ChangeAttributes in HPNWLIB.EXE. 

If the object's properties are changed while the dialog 
box is displayed, the information will be updated in the 
dialog box. This is achieved through the OMF message 
PROP_CHANGE. If an object has requested that property 
change information be sent to it by setting FLAG_PROP- 
NOTIFICATION with the OMF_ObjectFlag call, it will receive 
the PROP_CHANGE message from OMF when this happens. 
To notify the attributes box, the object must then pass the 
PROP_CHANGE information to a library function, which ex- 
tracts the useful data from the message and updates the 
property in the attributes dialog box. 

Moving Objects 

Objects in the NewWave Office are easily manipulated 
with the mouse. The user can move the mouse to the icon 
representing the object, and hold the mouse button down 
to select the object. By holding the button and moving the 
mouse at the same time, the user initiates the dragging of 
the object. As the mouse is being moved, the cursor changes 
to the shape of a rectangular frame with an arrow in the 
middle. The original icon representing the object is now 
grayed, giving the user direct feedback that the object is 
now in a transient state. Once the user decides where the 
object should be placed by lifting the mouse button, a whole 
series of operations and messages will be invoked to decide 
on the final placement of the object. 

Depending on the position where the mouse button goes 
up, the object can be placed according to various placement 
algorithms. The final destination may be an empty area in 
the same window, an area already occupied by an icon, or 
a different window. Moving to an empty area in the same 
window simply involves updating the data structure with 
the new x,y coordinates and drawing the object in the new 
position. Two other cases — moving on top of an icon, or 
containment as it is sometimes called, and moving to a 
different window — are more involved operations. 
Containment Move. When the object destination coincides 
with an existing icon, the containment move operation is 
initiated. Without waking up the icon object, inquiries are 
sent to the OMF to find out if the icon object has the appro- 
priate method to accept a new child. The method can be 
either ADD_CHILD or OMFJNSERT. The ADD_CHILD method 
allows the insertion of a new object without activating the 
object itself, and the OMFJNSERT method involves activat- 
ing the receiving object and sending it the message. 

If ADD_CHILD is supported, then the child can be added 
by OMF using the function OMF^AddChildTo. The file drawer, 
the wastebasket, and folders are examples of objects that 
support the ADD_CHILD method. When this method is pres- 



ent, the OMF can examine the property PROP_ADDCHILD to 
determine if the new child can be added. This property is 
a structure consisting of the reference name and the number 
of objects that can still be added. After the new child is 
added, the structure is updated by the OMF with the appro- 
priate values and is ready for the next OMF_AddChildTo call. 

When the container object is opened again, it will dis- 
cover all the new children added to it while it was inactive. 
As described earlier, during initialization the object enum- 
erates all of its children through the OMF_EnumChildren call, 
and the child objects that were added while it was sleeping 
will then be discovered and added to the object's data file. 
If new children arrive while the object is opened, the ADD_ 
CHILD message will be sent to the parent directly, and the 
updating of PROPJ\DDCHILD will be maintained by the ob- 
ject itself. 

If the ADD_CHILD method is not supported the container 
object is activated, and an OMFJNSERT message is sent in- 
stead. For example, when an object is moved to the printer 
icon, the process involves waking up the printer and send- 
ing it the OMFJNSERT message. 

The result of either the OMFJ\ddChildTo call or the OMFJN- 
SERT message is interpreted by the sender in the same 
manner. If the return value is TRUE, then the container has 
successfully accepted the new child, and the sender can 
now delete its OMF reference to the object and erase it 
from the screen. If the result is FALSE, then the object is 
not deleted from the sender's list, and its icon will be 
repainted again in its position before the move. The return 
of FALSE does not necessarily indicate a refusal to accept 
the child. In some cases, the container may accept the 
object being inserted, and return FALSE to the OMFJNSERT 
message to restore the object back to the sender. The printer, 
after adding the object as its child, uses this method to 
return the object to its original position. 
Moving to an Opened Window. When the object is moved 
outside of its own window, checks are made to ensure that 
the destination window is a NewWave object. To check 
whether the destination window will accept the object 
being moved, the HAS_METHOD message is sent to determine 
if the OMFJNSERT method is supported. If the return is an 
OMF value METHOD_PRESENT or NO_METHOD, then the des- 
tination is indeed a NewWave object. Other values may 
indicate that the destination is either a non-NewWave win- 
dow (e.g., a Microsoft Windows program) or the child win- 
dow of a NewWave object. The Microsoft Windows func- 
tion GetParent is used to find the handle of the parent if one 
exists. This handle is again used in the HASJVIETHOD in- 
quiry, and the search continues until the GetParent call re- 
turns a NULL handle indicating that there is no parent. 

Once a window handle is found that supports the OMFJN- 
SERT method, the object is then sent to the destination 
window with the screen coordinates of the destination 
point included in the message. When processing the insert, 
the receiver of the OMF message decides whether the object 
should be accepted and then returns a TRUE value if it is 
accepted and FALSE otherwise. The receiver may also de- 
cide that the destination point is occupied by another ob- 
ject, and in that case, will pass the received object to the 
container as described in the above section. 
Moving Multiple Objects. Multiple objects can be selected 
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by holding down the Shift key while selecting. Dragging any 
one of the selected objects changes the mouse cursor to a 
multiple-box frame with an arrow in the middle. The orig- 
inal icons representing the moved objects are grayed to 
indicate that these objects are now in a transient state. 
When the cursor has reached the destination, lifting the 
mouse button brings the objects to the new location. These 
objects are now positioned as a group at the destination 
location and staggered down and to the right from each 
other. 

Once again, the OMFJNSERT message is used when mov- 
ing a group of objects from one window to a different win- 
dow. Each object from the group is sent to the receiver 
window using the OMFJNSERT message. The sender is re- 
sponsible for setting the x,y coordinates in the data struc- 
ture that accompanies the message for the very first object 
of the group. The receiver calculates the coordinate posi- 
tion for each succeeding object and writes these values into 
the insert data structure. These coordinate values are used 
to position each object in the group. 

In all of the cases described above, the sender of the 
OMF message knows very little about the receiver and vice 
versa. These two NewWave objects determine whether cer- 
tain messages should be sent to each other by consulting 
with the OMF first. If the method in question is supported, 
then a message is sent to the receiver with the relevant 
data stored as predefined parameters or data structures. 
Once the message is received, the receiver can interpret 
the data or part of it according to its own established pro- 
tocol. For example, the receiver of an OMFJNSERT message 
could be a folder in the list view, and in that case the x,y 
coordinates in an OMFJNSERT message are ignored with no 



ill effects. The sender, on the other hand, is only interested 
in the return value from the message to determine whether 
the message was successfully received. The NewWave ob- 
ject model gives applications a high degree of flexibility 
to integrate with different object types without the need to 
understand the particular requirements of these data types. 



Conclusions 

A few examples have been chosen to illustrate the use 
of the object model in the implementation of the NewWave 
Office. By sharing the common code among a set of tools 
such as the file drawer, the wastebasket, and container 
objects such as folders, the user is presented with a consis- 
tent and familiar user interface. The reusability of some 
NewWave Office functions in NewWave applications, such 
as the creator and the attributes dialog box, further en- 
hances the integration of the entire NewWave environment. 
The NewWave Office not only plays a central role as the 
first NewWave tool the user encounters, but is also a close 
collaborator with the OMF to supply essential architectural 
support to all NewWave applications. 
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Agents and the HP NewWave Application 
Program Interface 

In the NewWave environment, an agent is a software robot 
that acts as a personal assistant for the user. The agent 
interacts with the applications through the application 
program interface. 

■ 

by Glenn R. Stearns 



TO IMPROVE THE PRODUCTIVITY and ease of use 
of workstation applications, products such as macro 
processors, script facilities, and integrated intelli- 
gent front-end processors are being incorporated into appli- 
cation programs. These allow the machine to do more of 
the work in performing a task. If these facilities are inte- 
grated into each application designed for a software envi- 
ronment, they can be accessed from the integrating environ- 
ment and operate across all the applications. 

One of these facilities, known as an agent, performs tasks 
on behalf of the user within and across applications. The 
agent is a software paradigm, like objects (see article, page 
9). The agent is added to the system to increase its intel- 
ligence. Objects provide the capabilities the agent has at its 
disposal. The agent uses the objects in an intelligent way 
to perform work on behalf of the user. 

Categories of Agent-Like Products 

When current agent-like products are grouped together, 
three categories emerge, along with an overall pattern (see 
Fig. 1). The categories range from keystroke processors to 



integrated intelligence across applications. 

The first category is the macro processors. These store 
keystrokes with record, playback, and edit facilities. Within 
this category there are macros built into applications, and 
there are macros that span applications. 

The second category is the script processors. These pro- 
vide a procedural language with structures and verbs based 
on the products they operate on. For example, communica- 
tion packages have script facilities to allow automatic logon 
and data downloading. The script verbs could include Logon 
or Connect. Within the second category there are scripts 
built into products, and there are also script facilities across 
applications. 

The third category is the intelligent processors. These 
have knowledge about the products they operate on. For 
example, a product may provide a natural language inter- 
face for user interaction with an application such as a data 
base. Within the third category there is integrated intelli- 
gence within applications and there is integrated intelli- 
gence across applications. For example, the same intelli- 
gence may be applied to a data base and a graphics package. 



Intelligent Features 



Integrated 
Intelligence 

Across 
Applications 



Integrated 
Intelligence 

Within 
Applications 



Has Knowledge 
about the 
Product 



x 



Semantic Features 



Scripts 
across 
Applications 



Scripts 
within 
Applications 



Procedural Language 
with Structures and Verbs 
Based on the Product 



Syntactic Macros 
Features across 

Applications 
Macros 
within 
Applications 
Keystroke 
Accessories 



Keystroke Recopy, 
Playback, and Edit 



Stages 



Fig. 1. Stages of complexity in 
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The NewWave agent is designed so that features from 
all of the above categories can be offered as technology 
permits. 

NewWave Agent Design Criteria 

Within the office, users view the computer as a means 
to accomplish a task. Their goal is not "doing data base" 
or "doing spreadsheet," but instead, "doing sales analysis" 
or "doing cost forecasting." Applications, such as the data 
base and the spreadsheet, are the tools the user employs 
in the tasks of sales analysis and cost forecasting. A New- 
Wave object is the combination of an application and the 
related data. Thus, the user interacts with objects to carry 
out tasks. 

The NewWave agent carries out repetitive tasks that the 
user would otherwise have to perform. It duplicates the 
user's operation of the system in a repeatable way. 

What should the agent do? An agent should improve 
productivity by being an automated office assistant, and 
should provide automated testing, demonstrations, and 
training. The agent should perform user-defined tasks, 
allow the user to schedule when those tasks get done, do 
the tasks unattended, and learn from the user. The agent 
technology should support simulation of user actions, com- 
mands, testing of user responses, and the integration of 
intelligent processes. 

Users must tell their agents what to do, of course. If users 
are to construct automated tasks or modify tasks that are 
provided for them, the operations must be presented to 
them in an understandable way. Users should not have to 
interpret what they have done or what they want their 
agents to do with the system in terms different from those 
in which they understand the system. In other words, the 
agent shouldn't require the user to work with a language 
that looks like {\F2}+"mydoc"+{CR} instead of SAVE "mydoc". 

To allow the agent to interact with the application at the 
command level, the application must participate in the 
interaction with the agent. The design requirements to do 



this must not restrict the application designers' ability to 
design and structure their applications as they wish. 

In designing the agent, we wanted not only to develop 
the necessary technology, but also to put in place an effec- 
tive process to bring theoretical work into our design, so 
we could build a platform for the future as well as deliver 
a product to our customers today. This process needs to 
be maintained over an extended period of time to ensure 
a smooth evolution of the agent facility. For example, the 
design of the agent and the application program interface 
needs to support the addition of artificial intelligence (AI) 
technologies in the future (see "AI Principles in the Design 
of the NewWave Agent and API" on page 35). 

Agent Capabilities 

The NewWave agent can be thought of as a personal 
assistant or software robot. Each workstation has only one 
agent. 

The agent is autonomous in that it can carry out instruc- 
tions without user intervention. The agent can also make 
decisions based on the criteria a user gives it. 

A user does many repetitive things on a workstation that 
can be turned over to the agent. These range from sending 
out reminder notices for meetings to looking up data and 
making decisions. The kinds of things you would have an 
agent do are the kinds of things you would expect a personal 
assistant to do for you with a workstation. You should not 
expect the agent to do things a personal assistant would 
not do. For example, the agent is not all-seeing or 
everywhere at the same time. The agent will only do one 
task at a time or look at one thing at a time. 

The Agent Metaphor 

The goal of the agent metaphor in the NewWave environ- 
ment is to draw upon the conceptual model of a personal 
assistant that users bring with them when using the system. 

Keeping the personal assistant metaphor in mind, the 
user locates the agent on the desktop in the NewWave 




Fig. 2. The NewWave Office desk- 
top display, showing the icons for 
the agent and the agent task. 
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Office by recognizing the iconic face (Fig. 2). By "tapping 
the agent on the shoulder" with a double click of the mouse, 
the user activates the agent and opens a window revealing 
the agent calendar. The agent calendar is used to define 
when the agent is to perform a given task. 

A task is a series of instructions for the agent to perform 
and is represented in the NewWave Office as an icon 
labeled Monthly Task (Fig. 2). The task can be opened by 
double clicking on it to examine and edit the instructions. 

If the user drags the task over to the agent, the agent will 
perform the instructions included in the task. 

Agent Task Templates 

When spreadsheets were first introduced, the user 
needed to learn quite a bit to build one. More complex 
spreadsheets required sophisticated work and debugging. 
When template spreadsheets were introduced, the power 
available to a first-time user was increased. By using a 
template and making some modifications the user got the 
desired results with much less work. The template pro- 
vided the first 80% of the effort and the user worked out 
the last 20% according to the specific needs of the job. 

Agent tasks can be used in this way. Application develop- 
ers can provide task templates to users of the NewWave 
environment. Users can then customize the template tasks 
to fit their specific needs. Users will also be able to make 
useful template tasks and distribute them within their or- 
ganizations. 

The Task Automation Spectrum 

The agent falls within a spectrum of methods of automat- 
ing tasks, and there is a point where it may be appropriate 
to develop a specific software application dedicated to a 
task. For example, if the task is time card entry, the user 
can perform it manually by filling out a paper time card, 
bundling it with all of the others, and sending the package 
via interoffice mail to accounting. 

This might be automated with the agent by writing an 
agent task that brings up a spreadsheet to collect the time 
card information and add it to a local data base. When all 
the time cards are entered that agent task would send the 
data base to accounting for merging with their dedicated 
payroll data processing system. Here the agent functions 
as an end-user programming environment, addressing the 
problem close to the source, and avoiding a data processing 
systems development effort to write low-level code for the 
computer. 

At some point, however, this solution may not be suffi- 
cient, and the user or others may deem that a specific 
software application needs to be developed. 

The Application Program Interlace 

The key element in the implementation of the NewWave 
agent is the application program interface (API), which is 
the interface between the agent and the application. The 
API provides the necessary and sufficient facilites to pro- 
vide task automation today and allow the addition of intel- 
ligence in the future. It is through this interface that the 
NewWave help, agent, and computer-based training (CBT) 
facilities interact with the application. 

The API is both an interface and an application architec- 



ture. The interface is made up of message definitions, ap- 
plication modes, code macros, and function calls in the C 
language. The application architecture is the organization 
of the application to support this interface. 

Fig. 2 on page 7 shows where the API fits in the New- 
Wave architecture. 

Applications and the API 

To support the API, an application must support five 
categories of interaction with it. These are recording, 
playback, interrogation, monitoring, and error handling. 

Recording support provides the API with the command 
the application just executed for playback at a later time. 
The format of the command is binary, is specific to that 
application, and is not expected to be viewed by a user, 
although like any machine or intermediate language, it can 
be examined and understood by the application designer. 

Playback support provides the application with com- 
mands to be executed as part of an agent task. The com- 
mands come from the agent by way of the API. 

Interrogation support provides help, agent, CBT, and 
other applications with the information they need about 
the application. For example, when the help facility is 
being used, the application will be interrogated to provide 
the specific help number for the area the user is pointing 
to within the application. 

During recording and playback, the source application 
may need to interrogate the destination application that is 
receiving an object from the source. This is because the 
source may only know the screen coordinates of the oper- 
ations, but needs to record or playback a meaningful com- 
mand. This allows the recording of a command like MOVE_ 
TO FOLDER "Sam" WITHIN FOLDER "Mary" instead of MOVE_TO 
123,346.* It is the destination application object that knows 
that 123,346 is FOLDER "Sam". 

Monitor support allows CBT to intercept an application 
command before it is executed, and provide corrective tuto- 

•123,346 is a screen coordinate pair. 




Fig. 3. The main feature of the application architecture is the 
splitting of the application code into an action processor and 
a command processor. 
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AI Principles in the Design of the 
NewWave Agent and API 

The field of artificial intelligenge, or AI, is made up of many areas 
of concentration, including expert systems, natural language, 
planning, cognitive psychology, and robotics. In the design of 
the agent and the application program interface (API) for the HP 
NewWave environment, the area of robotics was drawn upon, 
with the agent modeled as a "software robot." 

The basic agent architecture as depicted in AI research, is 
made up of three components: the agent, the world, and the 
knowledge base containing the agent's knowledge about the 
world. 1 There are two main relationships: the relationship be- 
tween the agent and its knowledge base and the relationship 



rials. The CBT lesson can elect either to let the command 
go through to the application for execution, or to ignore 
the command so the application does not execute it. See 
the article on page 48 for more information about CBT. 

Error handling support provides the agent, via the API, 
with any error conditions that occur during execution of 
a command. These error conditions can be trapped within 
an agent task so error recovery can be performed. 

Application Architecture 

To support these interactions, the application must be 
designed to do so. This design we call the application ar- 
chitecture. The major design concept is the splitting of the 
application between the portion that interacts with the syn- 
tactic user actions (keystrokes and mouse moves) and the 
portion that interacts with the semantic commands that 
result from one or more user actions. The two portions of 
code are called the action processor and the command 
processor (see Fig. 3). The agent, the help facility, and the 
CBT interface with these in a predefined way. 

The agent must be able to record commands after they 
are generated and play them back to the command proces- 
sor, as well as monitor the commands before they are exe- 
cuted. Therefore, the agent interfaces with the application 
between the action processor and the command processor. 
For support of user action monitoring and playback by 
CBT, the agent also interfaces before the action processor 
through the application program interface. Help facility 
interrogation of the application also occurs before the ac- 
tion processor, also through the application program inter- 
face. The agent engine provides the execution of agent tasks 
for task automation and CBT. 

On a more detailed architectural level (Fig. 4), the appli- 
cation can be thought of as organized into processors, 
which the application writer designs and constructs, and 
components, which are supplied as code fragments to the 
developer to be placed within the application. It is the 
relationship of these processors and components that al- 
lows the API to interface to the application. 

Extensible Task Language 

The results of the application architecture can be seen 
by looking at an example of recording a command, viewing 
it, and playing it back (see Fig. 5). For more information 
on the NewWave task language, see the article on page 38. 

An agent command takes on several forms as it moves 
through this process. There is the form in which the user 
sees it — for example, SELECT "XYZ". This is the task lan- 
guage form. There is the form in which the command is 
stored for playback via the agent. This is the P-code form. 
There is the form of the command when it is transferred 
from the agent to the application. This is the external form. 
There is the form the application uses during execution 
within the application. This is the internal form. 

Assume that the application is in record mode and the 
user operates on it with several user actions. These are 
analyzed by the action processor and a command is gener- 
ated. 

The command may be the selection of an object on the 
screen. Because the objects are kept in a list within the 
application's data structure, the command's internal form 



between the agent and the world, Much work has been done on 
the relationship of the agent and its knowledge base, but less 
has been done on the relationship of the agent and the world. 
In developing the NewWave environment we have concentrated 
on the relationship of the agent to the world of NewWave objects. 

If the agent is a software robot, then by analogy, it should 
interface to the software world much like a hardware robot inter- 
faces to the physical world. What is necessary and sufficient for 
a hardware robot to interface to the physical world? First of all, 
a hardware robot needs effectors. These are the arms that cause 
change in the physical world. It also needs feedback to determine 
what its effectors are doing and to detect that an attempted 
movement has encountered an obstruction. Finally, the robot 
must have passive sensors to view the physical world and provide 
the needed feedback. 

The software equivalent of effectors is software commands to 
applications. Feedback is the return of application error condi- 
tions and status to the agent. For passive sensors, the agent 
interrogates the application's data. These are the robotics prin- 
ciples designed into the NewWave agent and API. Commands, 
error conditions, and interrogation are the necessary and suffi- 
I cient faculties for a software robot to interface to its software 
world. 

By providing the design guidelines and environment to support 
these faculties, the NewWave environment facilitates the building 
of software to support a software robot. The NewWave environ- 
ment does not presently supply the robot — the agent — with arti- 
ficial intelligence, that is, a knowledge base and inference capa- 
bility. Hence the agent needs to be programmed just as industrial 
I robots are. This can be done by leading the robot through the 
motions of the task, and in the case of the NewWave agent this 
is the record mode. Industrial robots can also be programmed 
using an appropriate procedural language, and in the NewWave 
environment this is the agent task language. 

However, like industrial robots, the NewWave agent can and 
undoubtedly will become more intelligent. The design of the agent 
and the API makes this straightforward by allowing intelligence 
to be added to the agent without changing the interface of the 
agent to the applications. Intelligence can be added to the agent 
in a plug-compatible way, so that different development organi- 
zations and companies can add their specific types of intelli- 
gence to the agent to meet their needs. 
Therefore, while the NewWave agent presently has no artificial 
| intelligence, the use of AI principles in the design of the agent 
! and the API will make it easy to add intelligence as technology 
permits. 
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may specify that element 1 be selected from the list. SELECT 
would be represented by a number. The command would 
read 6, 37, ptr[x], where the number 6 represents the length 
of the command and 37 the command number. Element 1 
could be represented by a pointer to an element x. The 
command processor executes the command, and because 
the application is in record mode, the command is passed 
to the processor that translates it to the external form. This 
processor is written by the application designer. 

The recording of the selection of element 1 would not 
be of value to the application, because the object may be 
moved around on the screen and become element 7, while 
element 1 may be replaced with another object. The internal 
form is what best serves the application designer's needs. 

Translated to eternal form, 6, 37, ptr[x] may become 8, 37, 
XYZ. In this form, the command can be preserved for later 
playback. 

The application transfers the external form of the com- 
mand to the agent via the API and the agent attaches a 
P-code to it, resulting in the command being in the P-code 
form. The agent has many P-codes for arithmetic and logical 
operations and for flow control that are executed by the 
agent without interaction with the application. One of the 
P-codes identifies that the parameters of the P-code form 
are to be sent to the application in external form. 

With the command P-code prefix, the command is sent 



to the agent task for recording. The agent task passes it to 
the class independent recorder. There are two categories 
of commands: class independent commands like IF, WHILE, 
and so on, and class dependent commands, which are spe- 
cific to an application, like the SELECT command. If this 
were a class independent command, the class independent 
recorder would produce the user-viewable task language 
form. However, in this case it is a class dependent com- 
mand, and it is passed off to the class dependent recorder 
for the specific application the agent is interacting with for 
this command. The class dependent recorder produces the 
user viewable command SELECT "XYZ". This command is 
stored as a line of ASCII task language within the agent task. 

The user could be watching the recording as it is going 
on and would see the line of text displayed within the 
agent task's open window. The user can modify any task 
language that is viewable. When recording is completed 
the resulting task is compiled to be performed at a later 
time. 

If the user modifies the agent task language, the process 
is reversed. The task language form is compiled through 
the class independent parser for commands like IF, WHILE, 
and so on, and through the class dependent parser written 
for the application for application-specific commands. The 
results of compilation are stored within the agent task in 
P-code form. 



Modeless 
User Action 

Interface 
Component 



Modeless 

Action 
Processor 



Modeless 
Command 

Interface 
Component 



Microsoft Windows 



User Action 

Interface 
Component 



AAA 



Action 
Processor 



Translate-to- 
Internal 
Processor 



Application 
Data 



Command 
Interface 
Component 



Translate-to- 
External 
Processor 



Command 
Processor 



■ 


■ 


Return 
Interface 
Component 



Modal 
Dialog Box 
Processor 



Error 
Dialog Box 
Component 



Translate-to- 
External 
Processor 



Fig. 4. Detailed block diagram of 
the architecture of a NewWave ap- 
plication. 



36 HEWLETT-PACKARD JOURNAL AUGUST 1989 



Class 
Dependent 
Parser 



Task Language 
Form: 
Select XYZ 



Class 
Dependent 
Recorder 



P-code Form: External Form: 

LEN PCODE CLASSID LEN CMD PARMS LEN CMP PARMS 

in— ■nraira DIE9ESE9 



T 



Action 
Processor 



Class 
Independent 
Parser 



Class 
Independent 
Recorder 



Agent 
Task 






m 


Agent 









External Form: 
LEN CMD PARMS 

DIEElEQa 



Translate-to- 
Internal 
Processor 



Command 
Processor 



Internal Form: 
LEN CMD PARMS 

manual 



Translate-to 
External 
Processor 




Application 



Internal Form: 
LEN CMD PARMS 



API 

and 

Application Architecture 
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command forms to support the agent. 



During playback the agent reads the P-codes from the 
agent task object and passes the external form of the com- 
mands to the application. P-codes, like IF, WHILE, and so 
on, are executed within the agent engine and are not passed 
to the application. 

When the application receives the command in external 
form via the API, the application passes it to the processor 
that translates it to internal form. This processor is written 
by the application designer and produces the internal form 
of the command for execution by the application's com- 
mand processor. 

The cycle is now complete. Combinations of record, mod- 
ify, edit, and playback can be performed and the agent will 
reliably maintain the proper command forms. 
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An Extensible Agent Task Language 

With this language, users of the HP NewWave environment 
can create scripts to direct their NewWave agent to perform 
tasks for them. The language is designed for both novice 
and knowledgeable users. 



by Barbara B. Packard and Charles H. Whelan 



THE AGENT TASK LANGUAGE of the HP NewWave 
environment is a set of procedural commands that 
provide users access to the task automation func- 
tions of the NewWave environment. Scripts can be written 
to create, delete, modify, and otherwise manipulate New- 
Wave objects. The scripts are processed by an interpretive 
engine, which is part of the agent object. More information 
on the interaction of the agent, the task language, and the 
application can be found in the article on page 32. 

In the NewWave environment, each task is a separate 
object with associated data files. Tasks function across and 
within object classes and are supported by all NewWave 
applications. Upon opening a task, the user sees the con- 
tents of the file containing the task language commands, 
available for editing and compilation. When the user drags 
a task to the agent icon, the associated binary P-code file 
is executed. Task language commands have a verb/object 
syntax: 

(command keyword) [ parameter J, . . 

The parameter of a command may be either a keyword 
or a literal. Commands are line-oriented, but a continuation 
character is available to extend a command across the line 
boundary. A primary concern in the language definition 
was the mapping of the interactive user interface to the 
task language commands. To make the scripts as readable 
as possible, we wanted to have the command keywords 
reflect user actions. For example, if an action is ac- 
complished interactively by clicking on a menu item such 
as CUT, the corresponding task language command will 
contain that menu item as its command keyword verb. The 
parameter type is command dependent, but numeric, 
string, and keyword command parameters can be used. 

User Requirements 

Agent tasks will be created and executed by users whose 
expertise varies widely. The casual NewWave user will 
record a few actions within an object and save them as a 
task, which is executed to repeat the actions. The power 
user will construct complicated automated tasks, fre- 
quently for other users, that execute for a considerable time 
without user intervention. 

The novice, using the task language as a macro recorder, 
quite possibly may never look at the task language form of 
the task. This user will require ease of use and high perfor- 
mance. The power user will demand a language with at 
least the power of command languages in existing applica- 



tions such as Excel or DBase III Plus.* 

Our chosen model for the task language is the power 
user. The language is appropriate for constructing large 
automated tasks involving several applications. We have 
provided a conversational window facility, designed by 
the task writer and controlled by the task language script, 
which enables the task to receive user input and display 
information. Other features include variables, functions, 
task procedures, control statements such as conditionals 
and loops, and numeric, string, and logical expressions. A 
command parameter defined as a literal may also be an 
expression of the same type. 

We expect that in time many casual users will move 
toward the power user model. The language should be 
designed to facilitate this. Toward this end, the agent task 
recorder facility has a built-in watch feature. The user can 
see the task language command that was recorded as a 
result of an action. Recorded tasks do not contain the ad- 
vanced programming features listed above, but the relation- 
ship of the user's interactive actions to the task language 
commands will be apparent from the syntax of the com- 
mand. In particular, the syntax of task language commands 
is meaningful enough to serve as a learning aid to users 
who wish to explore the more advanced features of New- 
Wave agent tasks. This is another reason for the close map- 
ping of the command keywords to the interactive user ac- 
tions. 

System Requirements 

The system requirements for automating a task that spans 
applications have a somewhat different perspective. A task 
language statement is either a control statement (examples 
include variable assignment, procedure call, loops) or an 
action command (such as CLOSE, CUT, PASTE) to a particular 
object. Control statements are independent of the current 
active object and can be executed by the agent interpretive 
engine, but action commands are sent to an object of a 
particular application class and executed by it. Commands 
are not identical across applications; many are class-specif- 
ic. For example, most applications support some form of 
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Fig. 1. Binary P-code record format. 
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SELECT. But the object of the selection, which translates to 
the parameter of the task language command, will vary 
widely depending on the object class. In a document one 
would SELECT a range of text, in a spreadsheet a cell or 
range of cells. However, in the NewWave Office window 
the selection is an icon, that is, another object with a class 
and title. The NewWave open architecture specification 
mandates the dynamic installation and removal of applica- 
tion classes and leads to a different configuration on each 
system. Task language commands for a NewWave applica- 
tion written by an independent software vendor must also 
be supported. 

It is impossible for the agent engine to keep track of the 
command set and syntax supported by each application 
currently active on the system. The agent engine should 
not interpret the contents of a command it sends to an 
application in playback. It is equally impractical to have 
each application class parse its commands at execution 
time, returning similar syntax error messages, or handling 
variables or expressions as parameters. 

The solution is a task language parser module and re- 
corder template for each application class. The parser con- 
verts ASCII task language commands to the external com- 
mand form recognized by the application. The recorder 
template converts the external command to ASCII task lan- 
guage commands during the task recording. These are in- 
stalled into the task automation process when the applica- 
tion is installed into the NewWave environment. As appli- 
cations are added to and removed from the system, the set 
of task language commands accepted by the compiler and 
created by the recorder is customized accordingly. 

Application Developer Assistance 

Because developers of NewWave applications need to 
provide parser and recorder modules for task automation, 
we supply tools and guidelines to make their job as simple 
as possible. We separate out the components that are com- 
mon to all applications and provide code for these in li- 
braries, and we provide source templates for typical seman- 
tic routines. Since we wish to have the task language com- 
mands appear as one programming language to the user, 
we provide guidelines for commands and examples of 
appropriate syntax that are the same or similar across ap- 
plications. 

The Task Language Compiler 

Our first design decision was to compile task language 
scripts to a binary P-code format for execution rather than 
interpreting the ASCII commands at run time. There were 
several reasons for this: 

■ The binary format is more compact, particularly for long 
tasks. 

■ A standardized binary format is more suitable for execu- 
tion by applications in the MS Windows environment. 

■ Syntax and other obvious errors can be flagged and fixed 
at compile time. 



■ Nonsequential instructions such as loops and procedure 
calls can be handled efficiently. 

■ Functions, variables, and expressions can be preprocessed 
and handled in a standard manner. 

As a result, the task language compiler is a two-pass 
compiler. The first pass follows the general compiler model 
of scanner, parser, and semantics. It receives as input the 
ASCII task language script, parses it, and generates binary 
P-code records which are written to a temporary file. The 
second pass fixes instructions that reference addresses that 
were unknown when the P-code was initially generated. 

Object File Format 

Successful compilation of a task creates a binary object 
file. An object file consists of two main parts: a fixed-length 
header record and the binary P-code records which will 
be executed by the agent interpretive engine. 

The header record contains the version ID of the compiler 
as well as information such as the number of variables, 
conversational windows, and pages of code in the task. 

The code section of the object file consists of the variable- 
length, binary P-code records which are executed at run 
time by the agent engine. Many P-code instructions are 
similar to high-level assembly language. Pointers to loca- 
tions in the code are maintained as addresses. Addresses 
consist of a page number and an offset into that page, thus 
identifying the start of an instruction. Page size is fixed. 
P-code instructions do not cross page boundaries; however, 
a continuation P-code is available. 

The P-Code Record 

The agent interpretive engine performs a task by fetching 
and executing the P-code instructions. The generic record 
format is shown in Fig. 1. The length field contains the 
number of bytes in the record, including the length word. 
A record with no parameters will have a length of 4. The 
P-code ID is the numeric opcode of the instruction. The 
parameters are any parameters the instruction requires. The 
type and length are instruction dependent. Parameters of 
type string are null-terminated, which is indicated by the 
string \o. 

The Command P-Code 

As mentioned earlier, most P-code instructions result in 
an action command sent to a particular application object. 
Fig. 2 illustrates the P-code format for a command. The 
parameters of the P-code, except for the integer class ID 
word, make up the external command form, which is sent 
to the application. The class ID parameter is an integer 
indicating the class of object that recognizes this command. 
It is task dependent. The command length is an integer 
containing the total length of the length word, the command 
ID word, and the parameters. The command ID is set by 
the application. The parameters are of variable length and 
type, and are command dependent. 

At run time, the agent engine strips the first three words 



P-code Command Command Command Parameters 

Length Word P-code Class ID Length Word ID (Optional) 




Fig. 2. The P-code format for a 
command. 
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A NewWave Task Language Example 



Mary Smith starts the following task every Friday evening as 
she leaves work. The task cleans up her NewWave Office window 
by tidying up the past week's work. It then makes preparations 
for jobs that Mary will begin when she arrives on Monday morning. 

TASK 

FOCUS ON OFFICE 

Start by moving all data objects into a folder for the week and 
putting that folder in the file drawer. 

CREATE_A_NEW 
FOCUS CREATOR 

CREATE FOLDER TITLE "Week Ended 5/29" 

FOCUS OFFICE 

SELECT_ALL 

DISJOINT_SELECT FOLDER "Week Ended 5/29" 
move.to FOLDER "Week Ended 5/29" Moves all selected data 

objects into the folder 

SELECT FOLDER "Week Ended 5/29" 
MOVEJTO FILE_DRAWER 

Next, the task empties the waste basket. 

SELECT WASTE_BASKET 
OPEN 

FOCUS ON WASTE_BASKET 

EMPTY 

CLOSE 

FOCUS ON NEWWAVE_OFFICE 

Now, the task creates a spreadsheet, which Mary will use on 
Monday morning to prepare this month's profit and loss state- 
ment. The spreadsheet will be a copy of a customized master 
complete with prepared formulas and formats. 



CREATEJUMEW 
FOCUS CREATOR 

CREATE SPREADSHEET FROM MASTER CALLED "Monthly Profit And 
Loss" TITLED "May Profit & Loss" 

Next, the task will mail some memos that Mary wrote this after- 
noon. Since it is now late on Friday evening, the mail system will 
be more responsive. 

SELECT FILE_DRAWER 
OPEN 

FOCUS ON FILE_DRAWER 
SELECT FOLDER "memos" 
OPEN 

SELECT DOCUMENT "January Sales analysis" 

DISJOINT_SELECT TEXT_NOTE "Quick note about meeting Tuesday" 

DISJOINT_SELECT DOCUMENT "Next month's forecasts" 

MOVEJTO ENVELOPE "outgoing" 

SELECT ENVELOPE "outgoing" 

SEND_TO_MAIL_ROOM 

CLOSE 

FOCUS ON NEWWAVE_OFFICE 

Finally, the task will lock Mary's display. Her NewWave system 
will be locked until she unlocks it on Monday by giving her pass- 
word. 

LOCK_DISPLAY 
END 

ENDTASK 



and sends the remainder, the external command, to the 
application. The agent engine requires the length word; 
the remainder of the structure is designed by the applica- 
tion. However, applications are strongly urged to use the 
format illustrated. 

Run-Time Environment 

The agent interpretive engine is implemented as a simple 
stack machine. Variable assignments, function and proce- 
dure calls, and expression evaluations are all stack opera- 
tions. When a task starts up, the agent initializes its data 
structures using information in the task header record. It 
then makes an MS Windows intrinsic call to receive an 
MS Windows TIMER message at regular intervals. Each 
TIMER triggers a P-code fetch and execution. The agent re- 
linquishes control between instructions, thus allowing 
tasks to conform to the same execution guidelines as other 
NewWave objects. P-codes are fetched from the current 
page, which is retained in memory. Pages are procured as 
needed. If the P-code is a command, the agent checks the 
class ID to determine if the instruction class matches the 
class of the object that currently has the focus. If so, it posts 
an API_PLAYBACK_MSG to the object with the command as 



a parameter. No more P-code instructions are executed 
until the agent receives an APLRETURN_MSG. 

The Task Language Parsers 

To facilitate the modularization and customization of 
the task language, we designed a system of multiple parsers. 
The main compiler contains two parsers: the top level or 
class independent parser, and the expression parser, which 
handles functions and expressions of numeric, string, and 
logical type. Each application also has a parser module, 
which parses its class dependent task language commands. 
This module also includes semantic routines which con- 
vert the parsed command to the external command form. 
The parser modules are in the form of MS Windows 
dynamic libraries and are accessed from the class indepen- 
dent parser through the MS Windows LoadLibrary intrinsic. 
The application's installation file identifies the library file, 
the application class name, and the names of its parse 
routines by adding them to its OMF property list as a prop- 
erty PROP_AGENTTASKINFO. The task language compiler 
enumerates all applications with this property. It is then 
aware of all available classes of task language commands. 
Again, this can be different for each system configuration. 
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However, the compiler loads only the libraries of the classes 
requested by the task script. 

Parser Components 

The following sections describe briefly the various com- 
ponents of the parsers. Fig. 3 shows a data flow diagram 
of their interaction. 

Parser Routines. The current parser modules have been 
created using the yacc parser generator, yacc was developed 
at AT&T Bell Laboratories. There is nothing to preclude a 
developer's substituting a customized parse routine for a 
yacc-generated one. 

Keyword File. The recommended class dependent parser 
model stores its command keywords in a file which is read 
into a table during the initialization process. The token 
number of each keyword depends on its position in the 
file. This permits a certain amount of command localization 
without reconstructing the parser. 

Scanner Routine. The scanner was developed in-house at 
HP and provides the only access to the task language source 
file. All parser modules must call it for token input. The 
scanner returns token types and indexes to appropriate 
tables where the values are stored. If a parser module uses 
a different token representation, it can modify its scanner 
to retrieve the value at this point and continue processing. 
Expression Parser. The expression parser is available to 
the class independent and class dependent parsers. It is 
activated by a semantic call during the parsing of a com- 
mand. It processes tokens until it finds one that is not part 
of the expression. The associated semantic routines gener- 
ate P-codes to evaluate the expression and place the result 
on the engine run-time stack. The expression parser then 
sets the state of the scanner so that the next token request 
(by a command parser) will return a token type expression, 
which will satisfy the conditions of the parse. There is no 
requirement that class dependent parsers use the expres- 
sion parser. 

Semantic Routines. Since the structure of the external com- 
mand form is known only to the relevant application, the 
semantic routines must be the responsibility of the appli- 
cation developer. However, we have provided a library of 
routines to perform functions such as initialization, buffer 
management, and cleanup. Also, there are routines that 
handle the semantic processing of expressions when they 
occur as command parameters. Use of this library will 
greatly simplify the implementation of the semantics. The 
output of the semantic routines is returned to the compiler 
in a buffer and then written to the object file. 

The focus Command 

The compiler directs the source processing to the appro- 
priate parser through the FOCUS command. This command 
needs additional discussion since it results in both com- 
pile-time and run-time actions. The syntax is 



FOCUS 



[ ON ] (classname) 
[OFF] 



"(title string)" 



where classname is the name of the class of object (for exam- 
ple, DOCUMENT or FOLDER) as recognized by the task lan- 
guage parsers, and title string is the title of the specific object 



referenced. At installation time this classname is added to 
the OMF PROP_AGENTTASKINFO property of the class. When 
a task is compiled, the compiler adds the classnames to its 
list of keywords recognized by the scanner, and through 
the scanner by the class dependent parsers as well. 

When a task is executed, the majority of the commands 
will result in the agent's sending a message to the object 
that currently has the focus. The parameters of this message 
make up a command that will direct the object to change 
its state. At run time, the FOCUS command tells the agent 
which object is the target of subsequent command mes- 
sages. At compile time it has another role. It controls selec- 
tion of the class parser that will parse class dependent 
commands and generate the external command. Com- 
mands are compiled sequentially in the order received. 
However, the order in which commands are executed at 
run time will seldom, if ever, be completely sequential. 
The inclusion of conditional execution (IF, WHILE), jumps 
(GOTO), procedure execution (DO), or user variables in a 
task virtually guarantees that there is no way to make a 
determination at compile time which object will have the 
focus at run time. The FOCUS command sets a compile-time 
focus. In effect, it determines which class dependent parser 
will parse the commands following it. The command 

FOCUS DOCUMENT "Orders Report" 

will cause all class dependent commands to be parsed by 
the document parser until another FOCUS command is en- 
countered. If the OFF parameter is used, only class indepen- 
dent commands will be accepted by the parsers until 
another FOCUS statement is encountered. The main effect 
of this command is to reduce compilation time, since a 
syntax error returned by a class dependent parser will cause 
the command to be reprocessed by the class independent 
parser. 
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Fig. 3. Parser data flow. 
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The Task Language Recorders 

Task recording provides the ability to monitor run-time 
events and recompose them to produce a reusable task in 
the ASCII task language format. The focal point of the re- 
cording process is the class independent recorder. This 
module is an MS Windows dynamic library which is loaded - 
only during a recording session. It receives all external 
commands from the agent while recording is active. 

The recorder first determines if the received command 
is specific to a class. If it is not, the command is immediately 
converted to its ASCII task language form. If the command 
is class-specific, the library will either provide default de- 
pendent recording or will pass the external command to a 
separate class dependent recorder module. In either case, 
the completed task language text is used to build a source 
file of ASCII task commands. 

Default Dependent Recording 

The majority of class-specific external commands are 
handled wholly within the class independent recorder. 
This module uses ASCII recorder template files to provide 
the necessary information to do default dependent record- 
ing. These files provide formatting information so that a 
multiplicity of external commands can be recomposed into 
task language without the need of invoking class-specific 
executable code. 

Recorder template formatting strings are patterned after 
the C programming language's print control strings. They 
describe how a given external command's parameters are 
to be interpreted and formatted into compilable task lan- 
guage text. They can include information on the order of 
parameters in the external command, the size of each pa- 
rameter, the data type of the parameter, and how the param- 
eter is to be formatted in the task language line. Templates 
also support arrays of parameters, enumerated parameters, 
optional parameters, and optional fields in the task lan- 
guage form. Comment fields, ignored by the recorder but 
useful for documentation, may be included as well. 

Template file information for a particular class is read 
into memory when a FOCUS command for that class is first 
received during a recording session. As external commands 
are passed to the recorder at run time, they are then format- 
ted into task language. 

The example below illustrates a template and a command 
definition from the NewWave Office recorder template file. 

Template Formatting String: 

"%v %1d COPIES TO DEVICE %2s" ; 13th template. 
Command Definition: 

103 13 "LIST" 

The command definition specifies that when external corn- 



Length Number-of-Copies 
Word Parameter 




Command ^» Device Name Parameter 

ID Word 



Fig. 4. LIST external command format. 



mand 103 is received (and NewWave Office has the focus) 
the 13th template in the file is to be used with the verb 
LIST. The template definition specifies that the first param- 
eter in the external command is a decimal integer and the 
second parameter is a string. 

The external command form of the example is shown in 
Fig. 4. From the external command shown, default depen- 
dent recording will produce 

LIST 2 COPIES TO DEVICE •'LaserJet" 

Class Dependent Recorders 

If there are cases that cannot be handled by template 
files, an application can provide its own class dependent 
recorder. The class independent recorder will pass the ex- 
ternal commands that it cannot handle by default recording 
to the class dependent recorder for the class that currently 
has the focus. 

Extensibility 

All recorders including the class independent recorder 
are written as MS Windows dynamic libraries that are 
loaded only when needed with the MS Windows intrinsic 
LoadLibrary. All recorders must also support a common pro- 
grammatic interface, so that the interactions between the 
class independent recorder and any class dependent re- 
corder are identical. 

The developer of a new application can implement re- 
cording by producing the ASCII recorder template file and, 
if necessary, by developing the application's own sepa- 
rately linked dynamic library. The file names are declared 
in the PROP_AGENTTASK_INFO property in the application's 
installation file. Recording is activated when the running 
application gets the focus during a recording session. 
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The HP NewWave Environment 
Help Facility 

The NewWave environment provides a common, context 
sensitive, intuitive, unobtrusive help facility for NewWave 
applications. 

by Vicky Spilman and Eugene J. Wong 



DURING THE INVESTIGATION AND DESIGN phases 
of the help facility for the HP NewWave environ- 
ment, the development team followed objectives 
passed down from the system level. Among these were 
ease of use, emphasis on the tasks instead of the tools, and 
consistent user interfaces. The decision had already been 
made to include a help facility in all components of the 
NewWave environment. The decision was easy because 
customers expect some form of on-line help and there was 
a general desire to reduce the need for users to refer to the 
manuals. Other objectives were also added specifically for 
the help facility, but all of these objectives can be sum- 
marized by four descriptors: common facility, context sen- 
sitive, intuitive user interface, and unobtrusive. 

Common Facility 

Since every NewWave component has to supply help, it 
makes sense for help to be implemented as one facility that 
can be called by each component. Help runs as a separate 
program in the Microsoft Windows environment, like the 
other NewWave architectural components. However, help 
does not depend upon the NewWave architecture since it 
has to provide services for the NewWave Office, NewWave 
formatter. NewWave agents, other architectural compo- 
nents, and NewWave applications. Since the help facility 
is concentrated in one program, it can afford to provide 
additional features that would have been prohibitive to 
implement in multiple components. The character display 
formats, related topics buttons, window movement, and 
other functions are examples of features that would have 



been duplicated. 

The use of a shared program to provide help also guaran- 
tees that the help user interface is identical for all NewWave 
components. All displays look alike and all user interface 
features work identically across NewWave applications. A 
user can ask for help in the same way, regardless of whether 
the request is for a reminder of the purpose of an icon or 
for information on how to perform a specific operation on 
some data. 

A common help facility also gives the NewWave de- 
veloper several advantages. One obvious advantage is that 
the developer of an application does not have to develop 
the help facility. Also, maintenance of the application is 
simplified, since it uses the existing help facility. The help 
text can be written as a separate activity from the applica- 
tion code development, further reducing the workload on 
the developer. Help text maintenance is also easier since 
this text is separated from the other text materials in the 
application code. 

Context Sensitive Help 

For the help facility to be useful, it has to meet the expec- 
tations of users, which means that it should be context 
sensitive. When a user asks for help, the resulting informa- 
tion applies to the specific situation at that moment, instead 
of to a general situation, which might not provide any 
meaningful information to a user at all. For example, a user 
who needs to know how to use a text input box in the 
middle of a screen is not interested in finding out that the 
screen is used to communicate information and to get many 
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index. 
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types of input. The user would rather have — and gets — in- 
structions on what a correct entry might look like or what 
choices are expected. 

Intuitive User Interface 

In most cases, a user can look at the screen and figure 
out how to use the help facility without a lot of training 
or searching through the manuals. Thus one can get help 
immediately when it is most needed, when a small hint or 
short explanation will allow the task to be completed with- 
out a long delay or distraction. Help can be started from a 
menu, from a function key, or from a pushbutton. Index 
items can be chosen by mouse scrolling, keyboard scrolling, 
or typing. The help user interface allows all common modes 
of operation so that its use will seem intuitive to as many 
users as possible. 

Unobtrusive 

Help has to be able to meet the needs of users without 
becoming another problem. Therefore, it allows flexibility 
and yet remains efficient in execution and use of memory. 
The help window is large enough so there is room for 
explanations, but users can still see their original tasks. If 
it is necessary for them to see more of the previous window, 
they can move the help window out of the way or make it 
disappear until they want to make it reappear. If they move 
the help window aside, they can continue working on the 
previous task and refer back to the information given in 
the help text window. 

Starting Help 

To start help, the user can select one of two menu items 
from the help pull-down menu. The help pull-down menu 
for NewWave objects contains two items: Help Index and 
Screen/Menu Help. The menu items activate the help index 
and screen/menu help mode, respectively. The user can 
make the selection by using the mouse or by using ac- 
celerators (keyboard interface). The accelerator for gaining 
access to the help index is f1 . 

The user can also start help by selecting the help pushbut- 
ton from a dialog box. When the help pushbutton is 
selected, the help text window containing information per- 
tinent to the dialog box is displayed. 



Screen/Menu Help 

As mentioned above, one of the major objectives for help 
is to provide context sensitivity. Context sensitivity is best 
illustrated by screen/menu help mode, which is also called 
? mode. The user selects screen/menu help from the help 
pull-down menu and the cursor changes to a question mark 
shape, indicating that the user is in a special help mode. 
The user can move the question mark cursor around on 
the screen and click the button on the mouse when the 
cursor is on an area of interest. The verbal equivalent of 
this action is to ask the question "What is this?" while 
pointing at the referenced area. 

Screen/menu help allows the user to get help on anything 
in the application window, which might include pull- 
down menus, icons, and fields. When ? mode is activated, 
the Screen/Menu Help item in the help pull-down menu 
changes to Cancel Help, which allows the user to exit the 
mode without having to select a help topic. 

When the user activates screen/menu help and selects 
an item, the help window displays information about that 
item instead of executing that selection. After the help 
window is displayed, the mouse cursor and the help pull- 
down menu are restored to the previous state. ? mode is 
active for one selection at a time. 

Index 

The index will be displayed when the user selects the 
Help Index item from the pull-down menu, or activates the 
Index pushbutton from the help text window. The main 
purpose of the index is to list all available help topics and 
allow the user to select a topic. The index facilitates a quick 
search for a particular topic or allows the user to read all 
topics. An example of the index is shown in Fig. 1. 

All topics are listed in a standard listbox with a vertical 
scroll bar. With one exception, all topics are listed alphabet- 
ically. The one exception is the first index entry, which at 
the help text writer's discretion, may be a special topic 
that should be pointed out to the user. Within the listbox, 
the user can scroll through the entire index and select a 
topic, which is done by double clicking with the mouse 
on a topic, or by selecting the topic and then the OK 
pushbutton. 

Another option for searching for a topic is to use the 
editbox, which appears above the listbox. This allows quick 
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access to topics listed in the index. As single characters 
are typed into the editbox, a search begins immediately to 
find the first string in the listbox that matches the characters 
typed in the editbox. Once a topic is highlighted in the listbox 
(signifying a match), the user can press Enter to select that 
topic. 

Help Window 

The user can view the help text window and the index 
as one window, since the windows appear in the same 
place on the screen (on top of each other) and only one 
can be viewed at a time. The index and the help text win- 
dow are separate windows and are programmatically han- 
dled differently. There is only one instance of help; the 
user would never see two help windows. 

The help window appears to the user as a modeless dialog 
box belonging to an application. The help window can be 
moved, and disappears when the application closes or 
iconizes. When the help window is initially displayed, it 
is placed in the lower right corner of the screen. The user 
can move the help window if it is obstructing the applica- 
tion; this will allow the user to work in the application 
and also view the help text. 

The help window displays the help topic title just below 
the help window caption bar. The help text is in 12-point 
Helvetica type, with options for bold, underline, and 
pushbutton (related topics) variations. The font variations 
are used at the discretion of the help text writer. If the 
topic text is longer than one screen (14 lines of text), a 
vertical scroll bar will be provided for single-line and page 
scrolling through the topic. 

The Index pushbutton is available from the help topic 
window to let the user select another topic. The Last Topic 
pushbutton allows the user to back through previously dis- 
played topics. A sample of the help text window is shown 
in Fig. 2. 

Related Topics 

Related topics are highlighted words or phrases within 
the help text that can be selected. The related topic high- 
light is a simulated pushbutton. When the user selects the 
related topic pushbutton, the help text pertaining to the 
related topic will be displayed. 

Help Components 

The NewWave help system is made up of three separate 
sections or pieces: the user interface, the help files, and 



the help file utility. 

User Interface. The user interface refers to what the user 
sees and interacts with on the screen. The user interface 
can be further separated into two parts, which are separate 
executable modules. 

The first part, or the front end, of the user interface code 
is contained within the application and performs indepen- 
dently of the back end. The front end is a dynamic library 
used by all NewWave applications, thereby giving the ap- 
plications the common help interface. This benefits the 
user because access to help information is consistent be- 
tween applications. The front end portion of the help sys- 
tem is contained within the NewWave dynamic library 
HPNWLIB.EXE, which is used by all NewWave applications. 

The front end handles all of the help system functionality 
for the application. The front end initializes and maintains 
the help pull-down menu, maintains the question mark 
cursor, and monitors messages. The front end provides the 
routines that allow the application to communicate with 
the help system. In the NewWave environment, applica- 
tions make API function calls, which in turn call help. The 
front end loads the back end into memory, begins execution 
of the back end, and then communicates with it. 

The second part, or the back end of the user interface 
code, is a separate executable file, HPHELP.NWE, which is 
loaded by the front end. The back end does all of the help 
window maintenance (both the help text window and the 
index) and reading of the help files. The back end also 
maintains the connection to an application, since the con- 
nection changes when a second application asks for help. 
Most of the error handling is processed in the back end. 
Fig. 3 shows the pieces of the user interface. 
Help Files. The help files are located on the disc in the 
same directory as HPHELP.NWE. For consistency, the help 
files are named with the application name and the .HLP file 
extension. There is one help file for each application and, 
with the current help system design, one help file can be 
used at a time. 

The help file is a binary file that contains the structures, 
pointers, and help text required by the user interface. The 
format of the help file is shown in Fig. 4. The file header 
contains information about the entire file, such as pointers 
to the index table and context table and the lengths of the 
tables. There is one text block for each help topic in the 
file. Each text block has its own header describing the topic 
title and the number of related topics. The help text follows 
the text header, and the pointers for the related topics are 
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placed after the text. Following all the text blocks is the 
context table containing the context numbers provided for 
? mode. Last in the file is the index table which is used to 
display the help index. 

Help File Utility. The function of the help file utility is to 
produce a file that is readable by the user interface code. 
The help system requires tables and pointers that are dif- 
ficult to input manually. Therefore, the help file utility 
produces the desired results. The help file utility is basi- 
cally a file converter, converting the text input by the help 
text writer to the desired format. 

The utility, HPHELPFL.EXE (help files), is a DOS program 
that doesn't require MS Windows to run (however, it can 
be run with a PIF* file under MS Windows). HPHELPFL.EXE 
is not part of the NewWave environment, but rather a de- 
velopment tool that is used by NewWave application teams, 
help writers, and localizers. 

How Help Works 

As mentioned above, the help facility is an independent 
program. It is called by the application program interface 
(API) whenever the API detects a request for help while a 
NewWave program is executing. 

The API is the primary interface between an application 
program and the rest of the NewWave environment. The 
API provides the functions that must be called by the ap- 
plication program code to start the program, stop the pro- 
gram, display API menus, and call other system services. 
These functions give the API the information to inform the 
help facility of the state or location of the application pro- 
gram whenever a user requests help. 

For the NewWave programmer, there is no extra work 
involved to get the use of the help facility. If the program- 
mer follows the standard NewWave guidelines, which in- 
clude the API functionality, and provides a help file, the 
help system will automatically be provided for the applica- 
tion. 

The following is a list of the API functions and the help 
facility counterparts. The functions are all part of the 
generic API template for NewWave applications and are 
included in the HPNWLIB module. 

"A PIF Me is a program information file that tells MS Windows how much memory to reserve, 
and whether the application Is windowing, nonwmdowing, nonswitching. or nontransferhng 



/topic=Edit menu commands 
/related = Copy 

related = Cut 

related ■ Paste 

related = Select All Objects 

related=Share 

related = Throw Away 

The Edit menu contains the commands associated 
with the Clipboard. You use the Clipboard to transfer 
information from one item to another. 

These commands appear in the Edit menu: 

m Copy/N 
/R Cut/N 
R Paste N 

R Select All Objects/N 

R Share N 

R Throw Away/N 

Fig. 5. An excerpt from a help source file. 



■ APIInit calls HELPJnitialise which initializes data structures, 
checks for the help file, and does general initialization. 

■ APIInitMenu calls HELPJnstallHelpMenu which attaches the 
help menu to the application's menu. 

■ APIUserActionlnterface calls HELP_CheckMessage which is a 
message filter that executes help commands. 

■ APITerm calls HELP_Done which closes the help window, 
frees memory, and handles general termination. 

To allow the user to get help from a dialog box, the 
programmer must provide a help pushbutton in the dialog 
box (in the resource file) and use the NewWave standard 
call APIDigUserActionlnterface, which calls HELP_Topic to dis- 
play the appropriate help topic. 

Internal Functionality 

All incoming help messages are processed by the front- 
end code. The heart of the front end and of the entire help 
facility is the message filter, consisting of APIUserActionlnter- 
face and HELP_CheckMessage. Help requests from the help 
pull-down menu come into the latter routine and all sub- 
sequent help functionality is generated from this routine. 
Because the API filters messages, the help facility receives 
only the messages that pertain to it. When the user selects 
an item from the help pull-down menu, messages are gen- 
erated and are directed to the help message filter. 

When the user selects ? mode, the help facility sends a 
message to the application, telling the application to set 
the mode flag to intercept on. The mode flag is a variable 
that is part of the NewWave architecture and is maintained 
by the application. Setting the mode flag causes all mes- 
sages to be sent through the help message filter until the 
help facility tells the application to set intercept off 
(another message is sent). When intercept ? mode is in- 
voked, the help facility maintains the ? cursor and inter- 
prets the help selection of the user. Once a selection is 
made with ? mode, intercept mode is turned off and a help 
message is generated to display the help topic. 

When the request for a help topic or index is received (or 
generated), the front end processes the message by loading 
the back end and then sending it the appropriate messages. 

The back end receives a message for displaying the help 
topic or index, then executes accordingly. The back end 
manages everything pertaining to the help text window 
and the index window, which includes reading the help 
file (text and tables), scrolling, window placement, font 
and related topics, and the last-topic stack. 

For dialog boxes, the APIDigUserActionlnterface behaves 
similarly to APIUserActionlnterface in that it is a message filter 
routine, checking all messages to see if the help pushbutton 
(or other API button) has been pressed. If the help pushbut- 
ton is selected by the user, then a help topic request is 
generated. 

Context Numbers for ? Mode 

The main task for NewWave programmers using the help 
system is defining and setting context numbers. A context 
number is a value that uniquely identifies a topic in the 
help file. All items that can be selected by using ? mode 
should have a context number in the help file. If there is 
no context number in the help file for an item that the user 
wants help on, the help system displays a message "No 
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help available for this selection," which is not very helpful. 
It is to the programmer's advantage to provide a complete 
set of context numbers. 

In the case of menu commands, the context number is 
the command identification number set in the resource file. 

When the user selects help in the client area, the front- 
end code sends a message to the application requesting a 
context number. The application responds to the message — 
API_INTERROGATE_MSG, case API_RENDER_HELP_FN — by re- 
turning to the help system a context value that pertains to 
the cursor position in the client area. The cursor position 
is given to the application within the APIJNTERROGATE. 
MSG message. The application can return a context value 
based on the current state or cursor position within fields, 
thus producing context sensitivity. 

Providing help for system menus and the nonclient area 
requires that the context values match those in windows.h 
(include file provided for MS Windows development). For 
example, to provide help for the caption bar, the value of 
HT_CAPTION is used in the help file. Nonclient area values 
are the HT_ values. 

Creating Help Files 

There is no help facility if there is no help file. Writing 
and developing the help text is a major task in providing 
help for an application. 

The source files for the help text consist of control state- 
ments and help text. Control statements identify features 
pertaining to a help screen and the help file. Control state- 
ments are also directives to the help file utility for setting 
up structures and tables. Fig. 5 shows an excerpt from a 
help source file, and Fig. 2 is the resulting help screen. 

Control statements are distinguished from the help text 
by the slash as the first character in a line of text. Here is 
a list of some basic control statements and their functions: 

/context = # Provides a context sensitive topic 

available through ? mode, 
/topic = string Declares string as a main topic that 

is listed in the index, 
/end End of the help screen, 

/indent = string Lists string in the index indented 

under the topic, 
/related ■ string Specifies where a related topic 

points to — i.e. .string. 

Any text (not control statements) between the /topic and 
/end statements is the help text that is shown in the help 
window. Text enhancements (bold, underline, and related 
topics) are specified within the text by marking the text to 
be enhanced. Besides the text enhancements, no other for- 
matting is done. The text appears as it was typed within 
the source. 



When the source file has the help text required for the 
application, it must be converted with the help file utility. 
The input to the help file utility is the source file, and the 
resulting file is the file used by the user interface code. 

Stand-Alone Help 

The help facility was first developed as a stand-alone 
facility to be used by MS Windows applications. During 
the development of the NewWave environment, several 
NewWave architectural component libraries were com- 
bined so that the applications only need to use one library 
to access these functions, rather than several libraries. 

However, there was still a need for an MS Windows help 
system for other products that run in the MS Windows 
environment, so the help facility is also usable as a stand- 
alone version. The difference is that the application makes 
help calls directly instead of API calls. Other than the pro- 
grammatic interface, there is little difference between the 
stand-alone and NewWave help systems. They both have 
the same user interface and operate in the same way. 

Localizability 

As in other NewWave and MS Windows applications, 
all help text strings are in a resource file. The strings can 
be translated into other languages and the resource file 
recompiled. There is no need to recompile and link the 
entire help system source code. This is a feature of appli- 
cation development under MS Windows. 

For applications using the help facility, the help text is 
easily translated by changing the help source and then 
producing a new help file with the help file utility. 
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NewWave Computer-Based Training 
Development Facility 

Computer-based training in the NewWave environment 
allows users to learn how to use the system at their own 
pace, and provides facilities for users to create their own 
computer-based training courseware. 

Lawrence A. Lynch-Freshner, R. Thomas Watson, Brian B. Egan, and John J. Jencek 



FORMAL TRAINING IS OFTEN ASSOCIATED with 
a crowded lecture room. Despite a long and success- 
ful history, classroom training is becoming increas- 
ingly expensive without a corresponding increase in effec- 
tiveness. The growing influence of computers provides a 
possibility for improvement: let the computer do all or part 
of the instruction. 

Computer-based training, or CBT, has been extensively 
used by the military for teaching everything from medicine 
to flying. Academia has also come to rely heavily on the 
patience of the computer, while bright colors, interesting 
music, and supplemental video all add appeal for a gener- 
ation raised on television. Industry has been slower to 
adopt CBT. Available courses are limited, equipment and 
software are expensive, and people have felt threatened by 
the new technologies. Most important, many people are 
unconvinced that CBT is effective, often because of bad 
experiences with unimaginative or boring CBT. 

Properly written CBT can cut costs while raising reten- 
tion and motivation. Achieving this requires a partnership 
between the courseware and the CBT authoring software: 
■ Ideal CBT courseware is flexible enough to handle a 
variety of student experience levels, provides task-based 
instruction immediately applicable to the job, is avail- 
able whenever needed, provides chunks of instruction 
relevant to the task at hand, and doesn't constrain the 
student because of its own limitations. 



■ Ideal CBT authoring software is simple to use with min- 
imal programming experience, provides a realistic learn- 
ing environment, costs very little, and allows courseware 
to be developed quickly and inexpensively in response 
to local needs. 

In creating the HP NewWave CBT facility, we set out to 
reach these ideals. Earlier experiences with commercially 
available CBT authoring and delivery systems showed the 
potential of CBT, yet also pointed out the limitations of 
conventional technologies. It was time for original thinking. 

NewWave CBT Facility Design 

Throughout the project, there have been four design goals 
for the NewWave CBT facility: it must use the NewWave 
architecture, it must provide effective courseware, it must 
simplify and speed the development process, and the 
courseware must be adaptable to local cultures and lan- 
guages with minimum effort. 

No commercially available CBT authoring or delivery 
system was available for either the NewWave environment 
or Microsoft Windows. To take advantage of the power of 
the NewWave environment, a CBT system needs a graphic 
display, full mouse and keyboard input capability, the abil- 
ity to span concurrently open application windows, and 
the ability to operate on what the students do and how 
they do it. CBT also must be started from within the New- 
Wave environment, since requiring a return to the MS-DOS 
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prompt for training would probably discourage people from 
using it. Finally, since the NewWave environment is capa- 
ble of running existing MS-DOS and Microsoft Windows 
applications (without providing many of the NewWave en- 
vironment features) the CBT must also provide some way 
of training on these applications, even if only by simulating 
them within the NewWave environment. 

The second requirement for the NewWave CBT facility 
was that it must provide the capabilities for an unparalleled 
level of quality in the CBT courseware. CBT is an integral 
part of the learning product strategy for the NewWave en- 
vironment. When properly designed and executed, CBT 
has proven to be successful and inexpensive. Our goal was 
to minimize the technical limitations placed on the lesson 
author by allowing for multimedia lessons (text, graphics, 
etc.), modularized courseware, and easy access from within 
the normal work environment. 

The third requirement for the NewWave CBT facility was 
that it must reduce the long development times tradition- 
ally associated with CBT courses. A typical hour of CBT 
takes between 300 and 500 hours to design, construct, and 
test. Much of this time is spent in programming the CBT 
logic and creating the screen displays, rather than in the 
instructional design itself. By providing efficient, easy-to- 
use tools, and by eliminating as much programming as 
possible, the NewWave CBT facility can make expense less 
of a consideration when deciding whether CBT is an appro- 
priate medium for a particular course. 

Finally, the courseware created with the NewWave CBT 
facility had to comply with HP's guidelines for localizabil- 
ity. The primary requirement is that text should be main- 
tained separately from program logic. This way, nontechni- 
cal translators can translate the lessons into local languages 
without having to delve into the source code of the course. 
Since translated text is often 30% larger than the original 
English version, the position, size, and proportions of the 
NewWave CBT text window had to be easily adjustable, 
with automatic text wrap and preservation of formatting, 
so that the localizers could ensure the legibility of the les- 
son without having to recode it. Finally, text within illust- 
rations had to be accessible separately (i.e., no bit-mapped 
text) so that the illustrations would not have to be redrawn 
to translate them. 

During its history, CBT has evolved into two families of 
technologies: 

1 Simulation. The CBT software is fully responsible for 
what the student sees, with all screen displays produced 
by the training software. Simulations have great flexibil- 
ity, allowing training on any real or imagined subject, 
but require more development effort because an entire 
environment must be recreated. 

1 Concurrent. A CBT engine resides in memory and runs 
in conjunction with a real software application. The ap- 
plication provides all its screen displays and computa- 
tions just as if it were being used normally. The CBT 
software sequences the lessons, supplies instructional 
text, and controls which keystrokes and commands are 
allowed to reach the application. Since the application 
supplies the bulk of the code, concurrent CBT is usually 
easier to produce, but few applications can interact with 
the CBT engine in a really meaningful way. 



The NewWave CBT facility is designed to maximize the 
advantages of both methods, providing text, graphics, and 
animations for vivid simulations and intimate communica- 
tion between the CBT lesson and the applications being 
taught. 

A Sample Lesson 

The best introduction to the NewWave CBT facility is a 
sample lesson. Fig. 1 shows the first of a series of screens 
that might appear during part of a CBT course about the 
NewWave Office. These screen displays, or frames, se- 
quence in response to student actions. 
Frame 1. The real NewWave Office (not a simulation) is 
running, with all of its normal tools and objects visible. 
Also showing is a real folder object, placed by the CBT 
facility specifically for this lesson. Overlaying the Office 
is an instructional window, which contains an explanation 
of how to open an object, and a pushbutton control. The 
student reads the text in the window and clicks the mouse 
pointer on the Next pushbutton to go on to the next frame. 
Frame 2. The window now contains an illustration of a 
folder, along with an instruction to the student to try open- 
ing the real folder. The directions are repeated for reinforce- 
ment. At this point, there are two options. First, the student 
can try to open the folder called "Samples." Second, the 
student can click on the Show Me pushbutton, asking for 
the CBT to do it once as a demonstration. We'll assume 
the latter choice for now. 

Frame 3. The instructional window now describes the first 
step in the open process. The mouse pointer, by itself, 
slowly moves from its previous position to the folder "Sam- 
ples" and pauses. 

Frame 4. The window now changes to display the second 
step. The screen reacts to the double-click performed by 
the CBT facility, and the folder begins opening. The mouse 
clicks are not simulated; instead, the real message is in- 
jected into the system by the CBT facility. Beeps are 
sounded by the computer's speaker to mimic the sound of 
the mouse buttons clicking. When the student clicks on 
the Continue pushbutton, the folder is closed automatically 
and the next text frame is displayed. 
Frames 5-6. The student is now asked to open the folder 
unassisted, just as in Frame 1. If the open is unsuccessful, 
an appropriate remedial message is given, and the student 
is asked to try again, as in Frame 2. 

Frame 7. If the open is successful, congratulatory text is 
now displayed, and a brief animated reward appears. Then, 
using pushbuttons, the student chooses the next step: con- 
tinue to the next lesson, or return to the main course menu. 
In either case, the CBT facility closes the "Samples" folder 
and destroys it, so that it won't remain in the NewWave 
Office as an artifact of the training. 

The NewWave CBT facility is capable of monitoring the 
student's actions to a very fine level. The choice of which 
conditions to watch is left to the instructional designer, 
and will probably vary throughout a lesson. In this lesson, 
for diagnosing the cause of the open failure, some pos- 
sibilities might be: 

■ An open was attempted, but on the wrong object. In this 
case, to save time and distraction, the open operation 
can be prevented, with an appropriate message being 
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substituted. 

" The mouse was double-clicked, but off the folder icon. 
H The folder was selected (by a single click) but not opened. 

Here, a time-out would be used to assume the action had 

not been completed. 

■ And so on. The number of monitored possibilities is 
limited more by the designer's imagination and time 
constraints than by technology. 

An Overview of CBT Components 

The initial vehicles for CBT were the NewWave agent 
and the NewWave application program interface (API). As 
a task automation facility, the agent can sequence through 
a series of steps either automatically or in response to in- 
teractions with the computer user. The API provides a door 
into all consenting NewWave data objects and tools, allow- 
ing the agent to control them or determine their inner states. 
Together, the agent and the API can automate anything a 
user might do. Thus the basics for a powerful CBT toolset 
were present in the NewWave environment from the begin- 
ning. 

At its simplest, a CBT lesson is just an agent task (see 
article on page 38). Generic agent commands can open con- 
versational windows anywhere, display textual informa- 
tion, present pushbuttons for user control, monitor certain 
events within the system, and make sequencing decisions 
in response to user actions. 

While these agent tasks are sufficient for some training, 
they are not optimal for large-scale, highly visual CBT. 
They require programming expertise to construct, and be- 
cause of their size when used for CBT, are expensive in 
terms of development time and memory use. To construct 
superior training, we needed additional visual effects, full- 
screen graphics, the ability to simulate applications that 
didn't lend themselves to concurrent training, a more de- 
tailed knowledge of what the student was doing to the 
system, and a clean and easy method for starting and con- 
trolling a sequence of lessons. This required that the generic 
agent task language be supplemented by: 
B Extensions to the generic agent task automation language 
that perform training-specific actions such as mouse po- 
sition sensing and user input simulation. 

■ A CBT display object (with integral development editor), 



which displays the sequences of instruction windows, 
text, static graphics, and user controls that make up the 
student's view of a lesson. 

■ An animation object (and editor), which displays color 
or monochrome animated graphics. 

■ A CBT menu object (and editor), which displays the 
course's initial user interface and allows access to all 
instructional objects. 

12 Interrogation hooks coded deep within NewWave data 
objects and tools, which send information and perform 
actions in response to application-specific agent com- 
mands. 

In its current form, the NewWave CBT facility allows 
lesson authors to create full-color graphical and textual 
objects without writing a single line of code. A short and 
straightforward logical structure written in the agent's task 
automation language provides flow control for the lesson. 

Architecture for Application Training 

The NewWave architecture has been designed to support 
an integrated application training approach. This approach 
has its roots in concurrent training technologies, but has 
been taken much farther in the NewWave environment. 

To facilitate an integrated approach, NewWave objects 
are designed to communicate through the API. A typical 
application architecture includes a user action processor 
and a command processor (see Fig. 2). The user action 
processor collects user input (mouse movement, keyboard 
input, etc.). It takes no action until it detects that an input 
sequence has conformed to the syntax of a command. At 
this point, the user action processor sends the command 
through the API to the command processor, which pro- 
cesses the command and updates the object's state, data, 
and/or interface. Hence, the syntactic (element-by-element) 
user actions are translated to semantic (meaningful to the 
system) commands. 

When several objects are open under the NewWave en- 
vironment, all following this protocol, the agent has 
privileged access to monitor and examine commands that 
are sent by the objects through the API command interface. 
If desired, the agent may also filter a command from a user 
action processor, causing it to be ignored by preventing it 
from reaching its respective command processor. These 



Application 
Program 
Interface 



Syntactically 



Correct Commands 



Filtered 



Commands 



Action 
Processor 



(Check User 
Commands) 



User Input: Text, 
Mouse Clicks, etc. 



Screen Displays 




Display 
Updates 



Command 
Processor 



(Process 
Command and 
Update Object) 



Object State 
Data 



Object Files 



Fig. 2. An architecture for appli- 
cation training. 



50 HEWLETT-PACKARD JOURNAL AUGUST 1989 



techniques, called command monitoring and command fil- 
tering, are employed by training programs that are based 
on the agent and can be used to guide the user through 
learning and using NewWave applications. The primary 
advantages over previous application training technologies 
are: 

a Training programs do not need to simulate applications, 

since the real applications are used. 
■ Monitoring of application activities is at a semantic level, 
so the training program observes a command like OPEN 
FOLDER "Samples" instead of a sequence of mouse and 
keyboard inputs that must be interpreted. 
It is common for a NewWave application to provide al- 
ternative ways to issue any given command. Typically there 
are at least two alternatives, one using the mouse and 
another using the keyboard. In either case, the same com- 
mand is generated. This greatly simplifies the effort in- 
volved in developing training. 

The Agent and Agent Tasks. Agents can be thought of as 
software robots. The NewWave agent follows instructions 
from the user. It can automate tasks by sending commands 
to applications and can record tasks by receiving and stor- 
ing commands from applications. Additionally, the agent 
can monitor and filter commands, as previously men- 
tioned. The sequence of instructions that the agent follows 
is called a task, and the language in which tasks are written 
is the agent task language. 

Command Level Control. The easiest and most common 
use of the task language is to control NewWave applica- 
tions. For example, part of a task might be: 

FOCUS ON DOCUMENT "Letter" 
TYPE "Dear Chris," 

This tells the agent to direct its commands at (FOCUS ON) 
a document object called "Letter," and then to TYPE some 
text in the letter. Before it can receive agent commands, 
the letter must be open. This would have been done earlier 
in the task by: 

FOCUS ON OFFICE 
SELECT DOCUMENT "Letter" 
OPEN 

Here, the agent is instructed to direct commands at the 
main NewWave Office window, select the document object 
called "Letter," and then open it. Notice how the task lan- 
guage is modeled after the semantic activities of the user. 
Since the user would follow an identical sequence to open 
an object, this type of agent interaction is called command 
level control. 

Training tasks will typically control applications this 
way to initialize them for a lesson. For example, in a lesson 
on enhancing text within a document, a training task can 
automatically open the document and conduct other setup 
activities, rather than requiring these of the user. 

Additionally, training tasks can use command level con- 
trol to present instruction collected in a separate object. 
Consider the CBT display object, which is used by the 
training author to design a set of named instructional win- 
dows that can be randomly accessed. Within the lesson 



task, commands can be sent to the CBT display object to 
open instructional windows at appropriate times. At the 
beginning of such a task, the CBT display object is opened: 

FOCUS ON OFFICE 

SELECT HP_CBT_DISPLAY "Lessonl Instruction" 
OPEN_SHIFTED 

Later in the task, commands are used to display specific 
instructional windows: 

FOCUS ON HP_CBT_DISPLAY "Lessonl Instruction" 
GOTO_FRAME "How To Open" 

The command GOTO_FRAME advances the instructional 
sequence to the CBT display object's How To Open frame. 

This approach offers a significant benefit, in that training 
content in the CBT display object is conveniently separated 
from the training logic in the task. Hence, lesson content 
can be created, modified, and localized by nonprogrammers. 
Class Independent and CBT Commands. During the control 
of objects from an agent task, most of the commands used 
are specific to a class of applications, that is, they are class 
dependent. For example, GOTO_FRAME is a command that 
is specific to CBT display objects. Such commands are 
executed by the object that received the FOCUS command, 
and not by the agent, which only delivers the commands. 

To provide the rich syntax available in other high-level 
languages, the task language also has class independent 
commands such as IF..ELSE..ENDIF, PROCEDURE.. ENDPROC, 
WHILE.. ENDWHILE, and an assignment statement for vari- 
ables. These commands are executed by the agent. 

In addition to the generic agent commands used for all 
task automation, a set of commands specific to training 
development can be included by placing the CBT ON com- 
mand at the beginning of a task. Likewise, if these special 
commands are not needed, the CBT OFF command can be 
used to speed the language translation process. 
Command Level Monitoring. Many of the decisions made 
by the agent during a CBT lesson are based on the particular 
commands a student executes. To process the command 
activities of NewWave objects, two things are needed: a 
trap that recognizes that a command has occurred, and a 
procedure that interprets the nature of the command and 
acts on it. A typical implementation might be: 

ON COMMAND DO TrapProcedure 

SET COMMAND ON 

WAIT 

The ON COMMAND DO command is used to define which 
task procedure contains the interpretation and action steps. 
Once a monitoring procedure has been specified, monitor- 
ing must be turned on with SET COMMAND ON. This arms 
the trapping so that when any command is received through 
the API, the task jumps to the specified procedure. Typi- 
cally, the third command in such a sequence is WAIT. The 
WAIT command directs the agent to stop processing task 
language commands, and to wait for a command to be 
generated in a NewWave object. Essentially, the agent is 
idle until this condition is met. When a command is de- 
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tected, the agent executes the monitoring procedure and 
then resumes execution of the task, beginning with the first 
command after the WAIT. It is also possible for the agent to 
execute other commands in a task while it is waiting for a 
command trap, but this scenario is more complex. 

The monitoring procedure can contain any class inde- 
pendent commands. Its roles in a task are to examine com- 
mands that are trapped and to filter undesired commands. 
A monitoring procedure can use four class independent 
commands to acquire specific command information: the 
class and title of the object in which the command occurred, 
the type of command that occurred, and the parameters 
of the command. From the object's perspective, the 
monitoring procedure sits between the user action and the 
command processors, acting as a watchdog and a valve. 

The agent can simultaneously monitor several objects 
for commands. For example, a single trap procedure can 
be written to act on a command either from the object being 
taught or from the CBT display object. 
User Action Level Control. Although command level con- 
trol and monitoring are quite efficient ways to work with 
objects in a task, there are instances where the user action 
level is more appropriate. For example, the training task 
may need to distinguish between two alternative syntaxes 
of the same command to ensure that the user has learned 
one of them. The user action level is also inherently part 
of all Microsoft Windows-based applications. Thus, train- 
ing can extend into the domains of non-NewWave applica- 
tions at the expense of additional task complexity. 

One powerful use of user action level control in a training 
task is for demonstrations. In a demonstration, commands 
like POINT, DRAG, CLICK, DOUBLE-CLICK, and TYPE are used 
to manipulate objects with full visual feedback of mouse 
pointer movement and individual key entry. Command 
level control would not suffice for demonstrations, since 
it only shows the display changes that follow changes in 
object state, rather than the causes of those changes. 

Interrogation functions complement user action control 
by locating specific display elements. Class independent 
interrogation functions locate elements of the windowing 
interface, such as window caption bars and system menu 
boxes. These functions also locate elements that are man- 
aged by specific objects, such as a folder object icon within 
the NewWave Office window. Class dependent interroga- 
tion functions are used to ask the object questions like: 
Q Where on the screen is a display element? 

What display element is at a given point on the screen? 
■ What is the status of some condition within an object? 

Each of these questions deals with revealing information 
that is known only by the object. The first two questions 
map between display elements that are managed by the 
object and screen coordinates. For example, REGION_OF_OB- 
JECT returns a region, which is a data type that specifies 
a rectangular screen region by its origin (upper left point), 
width, and height. 

Together, user action level control and interrogation can 
be used to construct demonstrations that will always work, 
regardless of where elements of the demonstration have 
been moved. For example, to demonstrate how to open a 
folder object called "Samples": 



FOCUS ON OFFICE 

SAMPLES* = REGION_OF_OBJECT ("hpoffice folder". "Samples") 

POINT TO CENTER (SAMPLES*) 

DOUBLE_CLICK 

In these four commands, the office object is interrogated 
for the rectangular region occupied by the icon of the folder 
"Samples." The answer to the interrogation is assigned to 
the variable SAMPLES*. Finally, the mouse pointer is di- 
rected to move to the center of the icon, and then the effect 
of a left mouse button double click is produced. 

The CBT Display Object 

The CBT display object provides a fast, easy, and flexible 
way to create and display training-specific screens ranging 
from small and simple text windows to simulations of en- 
tire applications. 

The basic building block of a CBT lesson is the frame, 
which contains everything that might appear on the screen 
at any one time. By sequencing between frames, various 
textual instructions and graphical illustrations can be pre- 
sented to the student. Frames may be made up of any of 
the following: 

Windows, which can be full or part-screen. These can 
be any color, and can have various styles of borders. An 
elaborate window might look like a NewWave applica- 
tion window, with sizing controls, scroll bars, real 
menus, and so on. Windows are used as the framework 
to hold other elements, or can be used as backgrounds. 
Text, which comes in a variety of sizes, colors, typefaces, 
and enhancements. 

Controls, which can be pushbuttons, check boxes, or 
other forms. 

Color or monochrome bit maps, which can be input 
through the HP ScanJet scanner or MS Windows clip- 
board, or created using a built-in painter utility. 

■ NewWave environment icons, MS Windows stock icons, 
or icons loaded from a user-created file. 

Graphic primitives, such as lines, arcs, and circles, 
which can be drawn in various weights, colors, and fills. 
Animations, which are actually separate animation ob- 
jects controlled by the frame object. 

■ "Hot regions," which are invisible areas sensitive to 
mouse button clicks. 

A CBT display object contains one or more frames that 
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hold all of the displays needed for a complete lesson. Win- 
dows, menus, and controls are all real, but are connected 
to the intelligence of the agent rather than NewWave appli- 
cation code. 

Fig. 3 shows a schematic view of the sample lesson dis- 
cussed earlier. The frame sequencing for a lesson is handled 
by the agent. Simple statements command the CBT display 
object to display a particular frame. The student then per- 
forms an action such as opening an object, selecting from 
a menu, or typing in text or numbers. The task reacts to 
the action in a predetermined way by advancing to the 
next frame, requesting additional text, or presenting an 
error message. 

Without the CBT display object, input/output and dis- 
play control would have to be handled by the task language. 
With the CBT display object, the agent is used solely for 
decisions and sequencing. This greatly reduces the size of 
the task, minimizes the need for programming expertise, 
and speeds the lesson development process. 

When the lesson's final animation is played, a full-screen 
background window covers the NewWave Office, simplify- 
ing the display. The agent is responsible for coordinating 
the CBT display object and animation object. 



The frame editor can create very sophisticated screen 
displays. This allows the CBT to go far beyond simply 
displaying text on top of existing NewWave objects. It al- 
lows virtually any program to be simulated or prototyped, 
and allows courses to be developed on subjects far removed 
from software applications. Fig. 4 shows two such pos- 
sibilities. 

Program Structure. The CBT display object runs in two 
modes: development and run-time. The run-time version 
displays the frames inside the object, while the develop- 
ment version adds the editing facilities for text and 
graphics. If the object is opened by the agent, it assumes 
it is in run-time mode and displays the first frame. If the 
object is opened manually, it assumes it is in development 
mode and displays the initial editor interface, along with 
the first frame — if there is one yet. Since the CBT display 
object is hidden inside the CBT container object on run- 
time systems, it can only be opened manually by authors 
using a development system. Fig. 5 is a block diagram of 
the CBT display object. The painter (a bit-map editor) and 
the color selector are placed in dynamic libraries to maxi- 
mize code reuse, since they appear in several places within 
both the CBT display object and the animation object. 
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The CBT display object will usually be used to develop 
training that will run concurrently with one or more New- 
Wave objects. To simplify the synchronization of the CBT 
lessons with the applications, the development-mode 
frame object is designed to run unobtrusively on top of the 
object being taught about. This allows the lesson author to 
place windows and other frame elements optimally with- 
out having to guess what the final lesson will look like. 

The primary user interface of the CBT display object 
editor consists of a small window which contains menus 
and a list of frames. A new frame is created by typing a 
name in the Title field and clicking the Add button. Any 
frame can be selected for editing by double-clicking on its 
title. The CBT display object editor window can be moved 
around as needed so that the lesson author has access to 
the entire screen display without interference. 

Once a new frame exists, a window must be created to 
form a parent for all other elements in the frame. This 
window can be a featureless area used only to contain other 
elements, or it can be an integral part of the lesson. The 
opaque background or the simulated NewWave Office 
shown earlier in Fig. 3 are examples of these two variations. 

Recall that a frame can contain windows, text, controls, 
bit maps, icons, graphic primitives, animations, and hot 
regions. Each of these elements is created through 
specialized menus which provide easy and fast selection 
of various features. Once created, elements can be locked 
to prevent inadvertent movement or editing. They can be 
reselected for editing at any time, and can be moved, cut, 
or copied within or between frames. Additionally, text and 
bit maps can be imported from any NewWave or Microsoft 
Windows application using the MS Windows clipboard. 
When displayed, elements are stacked on top of one 
another, and if elements overlap, the highest one shows. 
The author can pull a given element to the top or push it 
to the bottom to control whether it is obscured by other 
elements. 

Internally, each type of element in a CBT display object 
is maintained in a single file, and when a frame is loaded 
into memory, all elements are fetched and readied for dis- 
play. While the files are essentially invisible in an object- 
based system, they may be specially accessed for the pur- 
pose of translating text to a local language. 
The CBT Display Object and the Agent. The CBT display 
object and all of its elements are designed for a high level 
of interactivity with the agent. Class dependent commands 
are used at run time to sequence between frames, hide and 
show various windows, launch animations, and sense 
when elements have been clicked on. All menus, sub- 
menus, and controls that appear in a displayed frame are 



real, but they are not connected to any application code. 
Instead, any frame element can be given a unique name. 
Class dependent agent commands are used to determine 
when a named object has been selected, and then the agent 
evaluates the choice and directs the frame object to display 
the frame that reflects the action. 

An optional "go to frame n" feature can be specified for 
any control (pushbutton) in any frame. Clicking on that 
element will cause the frame object to display a specific 
frame automatically, without any interaction with the agent, 
providing a high-performance, self-contained, hypertext- 
like capability. 

The Animation Object 

Animated demonstrations and graphics are often more 
instructionally valuable than static graphics, and can play 
a major role in keeping students motivated. The animation 
object is designed to provide high-quality animation with 
minimal effort on the part of the lesson author. 

The animation object is analogous to an ordinary ani- 
mated cartoon. It consists of a series of pictures which, 
when sequenced rapidly, give the illusion of motion. Fig. 
6 shows a typical animation object being created. The upper 
filmstrip display gives a low-resolution view of a bouncing 
ball in each of the four poses that make up its motion. The 
lower display is a detail view of a pose, which can be 
edited. When the sequence of poses is played, the ball 
appears to bounce in place. Moving the sequencing object 
horizontally as it plays makes the ball appear to bounce 
across the screen. 

Depending on its purpose, an animation may take several 
forms. An animation might be a single image, such as an 
arrow, which is given a velocity in some particular direc- 
tion, or it might consist of a sequence of poses that remain 
in the same place on the screen. Another form, such as a 
barnstorming airplane, might have a complex motion path 
and several poses. 

Each pose or cell in an animation is a bit map. These bit 
maps can be created in several ways: 

■ The integral bit-map editor can draw them directly, in 
either color or monochrome. 

■ They can be imported from any NewWave object or Mi- 
crosoft Windows application using the MS Windows 
clipboard. 

■ They can be hand-drawn on paper and scanned in using 
the HP ScanJet scanner. 

■ All or part of an image in one frame can be copied to 
another frame, where it can be used as is or modified. 
If desired, a combination of these methods can be used, 

so that a hand-drawn image can be scanned in and com- 
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bined with a bit map from another application, and the 
composite image colored using the editor. An image can 
be created on a black, white, or transparent background. 
An image can also have transparent areas painted on it, so 
that the actual screen display will show through the anima- 
tion when it is played. The editor also provides several 
alignment features, such as a grid, to allow the images to 
be positioned precisely for smooth movement. 

The initial position, velocity, and direction of an ani- 
mated image can be set using a menu in the editor of the 
animation object. If a complex path or changes in velocity 
are desired, or if the lesson author wishes to freeze or hide 
an animation during run time, the animation object's com- 
prehensive class dependent task language allows full agent 
control. 

Operation of the Animation Object. Like the CBT display 
object, the animation object has both development and run- 
time personalities, the difference being the presence of the 
editing facilities. The run-time version is primarily con- 
trolled by the agent or a CBT display object. The develop- 
ment version opens ready for modification, and provides 
only limited play capability for testing the animation. 

Animations are sequences of bit-map images, transferred 
one at a time to the display screen. Unlike ordinary car- 
toons, which own the entire screen of a television set, New- 
Wave animations must coexist with the other objects that 
appear on the screen. The animation object contains a pair 
of buffers which save areas of the screen that will be over- 
written by an animated image. Image bit maps are trans- 
ferred to these buffers, rather than directly to the screen. 
Once the buffers contain the correct display, they are trans- 
ferred to the display screen. When the animated image is 
about to move to a new point, the saved area is restored 
into the buffer to obliterate any trace of the image in its 
former position. 

An author will often crop an animated image with an 
irregular shape by surrounding it with a transparent back- 
ground. This allows the image to pass over other objects 
without a "halo" surrounding it. Transparent areas can 
also be drawn into an image so the screen background 
shows through. The technique used for this is analogous 



to the matte process used by filmmakers. An animation 
frame with transparent areas contains both its normal image 
and an automatically created mask, or outline, of the non- 
transparent part of the image bit map. When an image is 
written to the buffers inside the animation object, its mask 
is first combined with the buffer, removing all the colors 
from the area where the image will go. The mask is also 
combined with the image itself, removing the background 
and leaving just the picture part. The stripped image is 
then placed precisely over the "hole" left in the screen 
display. Since the two images are not actually combined, 
there is no interference between the screen and the image. 
The Animation Object and the Agent. The animation object 
has a rich class dependent task language which allows 
powerful agent control of a running animation. Animations 
can be started, frozen, or hidden, the course and velocity 
can be changed at will, or a programmed complex course 
can be loaded into the object in one step. Subsets of the 
frames in an object can be specified for display so that 
several different animations can be performed without hav- 
ing to load a new object. 

CBT Start-up and Menus 

A CBT lesson consists of an agent task object and a frame 
object, and may also contain one or more animation objects. 
A full CBT course will have many of these objects. If all 
had to reside openly in the NewWave environment, they 
would clutter the Office and confuse the student. To pre- 
vent these problems, all of the objects in a CBT course are 
contained in a special CBT global container object. It has 
many of the properties of other container objects like fold- 
ers, but remains invisible in a run-only system. 

The CBT global container object serves several purposes: 

■ It contains all of the CBT objects, simplifying the New- 
Wave Office display. 

■ It protects the CBT objects from accidental deletion or 
modification. 

A separate CBT menu object keeps track of topics and 
lessons: 

■ It provides a start-up capability for the various agent 
tasks that drive the lessons. 
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■ It presents a menu that allows the student to choose a 
particular lesson within a course, and maintains a record 
of which lessons have been completed. 

■ It accepts additional CBT lessons from newly installed 
objects and integrates them into the standard menu. 
To start CBT, the student pulls down the NewWave Of- 
fice's Help menu and chooses Tutorial. This opens the CBT 
menu object and displays its initial menu. First-time users 
will probably not have acquired the mouse skills needed 
to use menus in the ordinary way. To get them going, the 
NewWave Office comes with an autostarting agent task, 
which gives the new student the option of running the CBT 
by pressing the Enter key. This autostarting task can be 
disabled after the student takes the lesson, removing the 
overhead of the question when it is no longer needed. The 
CBT menu object also allows a lesson to be specified as 
the default, and pressing the Enter key will initiate the de- 
fault lesson. This provides a backup for those students who 
may be working on a system whose autostart training task 
has been removed. 

CBT menus are nested in outline form. Students choose 
a broad topic, and a submenu is then brought up that 
specifies the actual lesson titles. After a lesson has been 
completed, a check mark is placed on the menu to help 
the students track their progress. When a lesson is chosen, 
the CBT menu object dispatches the appropriate task to 
the agent, which then runs the lesson. When the task is 
finished, the agent returns control to the CBT menu object 
so the next lesson can be run. 

Developers of NewWave applications can write their own 
CBT lessons using the CBT development facility. As part 
of the installation process for the new application, its CBT 
is loaded into the CBT menu object and its menu structure 
is registered. This allows all lessons in the NewWave envi- 
ronment to be run from the same place, ensuring easy use 
and easy tracking of all lessons. 



Conclusion 

New hardware technologies such as voice, interactive 
videodisc, CD-ROM, and pen-and-paper input devices are 
all finding places in the training environment. The inherent 
flexibility and expandability of the NewWave architecture 
make it easy to incorporate new ideas, and the power and 
ease of use of the NewWave environment make it a natural 
vehicle for exploring new techniques. 

The NewWave computer-based training facility is still 
in its infancy, yet it contains features not found in other 
CBT systems. It embodies the true potential of the entire 
HP NewWave environment: to give knowledge workers the 
time to let their imaginations work and the means to make 
their ideas real. 
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Encapsulation of Applications in the 
NewWave Environment 

To allow non-NewWave applications to run in the NewWave 
environment, the NewWave encapsulation facilities provide 
features for the partial or full integration of these applications 
into the NewWave environment. 



by William M. Crow 



THE HP NEWWAVE ENVIRONMENT provides power- 
ful capabilities for applications that are written to 
take full advantage of the object management facility 
(OMF), the agent, and other NewWave features. However, 
there are thousands of personal computer software applica- 
tions currently available that were not written for the HP 
NewWave environment, or for that matter, were not even 
written to operate under Microsoft Windows. In many 
cases, these are mission-critical applications that organiza- 
tions depend on as part of their day-to-day operations. 
These applications may ultimately be replaced by better 
solutions that take full advantage of the HP NewWave en- 
vironment. However, if we expect users to begin using the 
HP NewWave environment today, users must be able to 
continue to use the software currently at their disposal. 

For an existing MS-DOS®-based application program to 
operate correctly in the HP NewWave environment, either 
the application must be modified, the HP NewWave en- 
vironment must recognize and accommodate the MS-DOS 
application, or an additional program must provide an in- 
terface between the MS-DOS application and the HP New- 
Wave environment. The HP NewWave encapsulation facil- 
ity uses a combination of all these techniques to provide 
a wide range of support for applications not specifically 
written to operate in the HP NewWave environment. 

In some cases, the encapsulation facility makes it possi- 
ble to continue to access applications that were in use 
before installing the HP NewWave environment, but offers 
no enhancement to their features or operation. In other 
cases, encapsulation makes it possible for existing applica- 
tions to take full advantage of the HP NewWave environ- 
ment without the need for a complete rewrite. For most 
existing applications, the situation lies somewhere be- 



tween these two ends of the spectrum. The basic levels of 
application program encapsulation in the HP NewWave 
environment are shown in Fig. 1. 

Microsoft Windows Multitasking and Context Switching 

Because the HP NewWave environment is based on the 
Microsoft Windows environment and runs on industry- 
standard workstations that support the MS-DOS operating 
system, it is always possible to run other applications by 
temporarily leaving the HP NewWave environment and 
the Microsoft Windows environment. While workable, this 
approach is not always practical, and certainly does not 
meet the objective of providing a complete environment 
for the HP NewWave user. Microsoft Windows improves 
on this by providing the necessary device and memory 
management facilities to allow multiple applications to run 
simultaneously. These applications may or may not be writ- 
ten for Microsoft Windows. A Microsoft Windows applica- 
tion will appear on the screen in its own window along 
with the windows of other Microsoft Windows applica- 
tions. Multiple Microsoft Windows applications can be 
executing simultaneously, depending on available mem- 
ory. The user interacts with them by using the mouse or 
keyboard to select the appropriate on-screen window and 
to enter information or select commands. 

If the application is not written for the Microsoft Win- 
dows environment, it can still be accessed and operate in 
conjunction with other applications through additional 
facilities provided by Microsoft Windows. Such an appli- 
cation will be given control of the entire screen, presenting 
its own display and user interface. The user can switch 
contexts between the full-screen application and Microsoft 
Windows with a simple keystroke sequence. Multiple full- 
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screen applications can be active simultaneously, depend- 
ing on the amount of available memory in the system. Full- 
screen applications are not truly multitasked by Microsoft 
Windows because an application's operation is suspended 
when it is not displayed on the screen. The complete state 
is saved and the application continues operation when the 
user once again gives it access to the display. 

The encapsulation facilities take advantage of this funda- 
mental capability of Microsoft Windows, and provide ways 
to operate MS-DOS-based applications from within the HP 
NewWave environment. 

The DOS Programs Service 

In its simplest form, the encapsulation facility provides 
an easy-to-use method to access and run other applications 
from within the HP NewWave environment. A user con- 
figurable menu of available MS-DOS applications is ac- 
cessed through the DOS Programs... command in the HP New- 
Wave Office. Selecting an entry from this menu starts the 
application, using the facilities in Microsoft Windows dis- 
cussed earlier. Fig. 2 shows the DOS programs service 
menu. 

Adding, removing, or modifying the menu of available 
applications requires no special knowledge or program- 
ming skills. The user can directly access a simple configura- 
tion command to make the applications chosen available 
through the HP NewWave DOS programs service. For many 
popular commercial applications, it is as simple as select- 
ing the desired program from a preconfigured list. 

There is virtually no other relationship or integration 
between the HP NewWave environment and an application 
encapsulated using the DOS programs service other than 
the ability to start it up. The application still accesses the 
MS-DOS file system to store and retrieve information. The 
user must be aware of the proper methods to specify 
filenames and navigate MS-DOS directories. Accessing 
data from these applications within the HP NewWave en- 
vironment requires an explicit process to import or convert 



the MS-DOS file to a form recognized by the HP NewWave 
object management facility (OMF). 

Because the DOS programs service is itself an HP New- 
Wave application, it is fully integrated with the agent facil- 
ity. HP NewWave agent tasks can access the service and 
start the operation of an MS-DOS application. However, 
the agent cannot monitor or control the operation of the 
application once it is started because that application was 
not developed with the necessary agent interfaces. Because 
many existing applications offer their own internal facility 
to automate a sequence of tasks, it may still be possible to 
integrate them into an overall automated solution. 

While the DOS programs service does not provide MS- 
DOS applications any integration with the HP NewWave 
environment, it is a useful tool for many users. In many 
cases, users need access to stand-alone applications that 
are critical to day-to-day business activity, but don't require 
integration with other applications or task automation ser- 
vices. In time, these applications can be replaced with HP 
NewWave solutions, but in the interim, the DOS programs 
service provides a useful solution. 

Generic Encapsulation 

The DOS programs service provides a method to begin 
encapsulation, but it still requires the user to perform all 
the necessary file management using the MS-DOS file sys- 
tem. An important contribution of the HP NewWave envi- 
ronment is the ability of users to access and manage infor- 
mation easily by using a mouse to manipulate iconic rep- 
resentations of the data. The HP NewWave environment 
provides a facility called generic encapsulation, which al- 
lows many MS-DOS applications to be easily configured 
and accessed in a similar manner. 

Using generic encapsulation, an MS-DOS application is 
installed as a unique object class. Data files created or ac- 
cessed by the application are treated as instances of this 
class, and can be represented by individual icons within 
the HP NewWave environment. The user can access and 
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manipulate these data files like any HP NewWave object. 
Through direct manipulation with the mouse, the user can 
open an object and the generic encapsulation facility will 
start the associated encapsulated application and automat- 
ically load the data file associated with that instance. Fig. 
3 illustrates direct manipulation of an encapsulated object. 
Direct manipulation can also be used to store, retrieve, 
move, copy, mail, or delete encapsulated application ob- 
jects, just like other NewWave objects. These encapsulated 
objects can be organized and stored with other HP New- 
Wave objects, allowing the user to manage all information 
in a similar fashion, and shielding the user from most de- 



tails of the MS-DOS file system. The user can even create 
data file sharing at the object level, allowing the same object 
to be stored in multiple places at the same time. 

Because these object-level features are implemented in 
a similar manner for a wide range of applications, the 
generic encapsulation facility is implemented as a single 
program that can be customized for different applications 
with a configuration file. The effort to encapsulate a new 
application is reduced from months of development time 
to a few minutes to set up the appropriate configuration 
information. 

Generic encapsulation does not allow the user to estab- 
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MICROSOFT TO INCLUDE HP NEWWAVE SUPPORT 
IN FUTURE VERSION OF MICROSOFT EXCEL 

PALO ALTO. Calif., June 20. 1988 •• Microsoft Corporation and 
Hewlett-Packard Company today announced an agreement to work 
together to develop and market the Microsoft(R) Excel spreadsheet 
program for the HP NewWave environment. 

HP NewWave is an advanced software-applications environment 
based on Microsoft Windows Version 2.0. It enables users to work across 
multiple applications and easily manipulate data from multiple sources. 

HP NewWave also improves personal-computer integration by 
providing PC users with a single view into an organization's entire network 
of information resources. 

'When enhanced with the systemwide services provided by HP 
NewWave. Microsoft Excel takes another step forward as the most 
powerful, flexible and intuitive spreadsheet product available today." said 
William H. Gates, chairman and chief executive officer of Microsoft. 
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lish views to or from the application. Views are data links 
that establish the parent-child relationship of compound 
objects in the NewWave environment. Generic encapsula- 
tion also offers only limited support for the HP NewWave 
agent. These features are not possible without direct partici- 
pation from the application itself, or a more sophisticated 
form of encapsulation that understands the specific data 
formats and operation of a particular application. 
Objects versus Files. One of the significant contributions 
of the HP NewWave OMF is to manage access to the MS- 
DOS file system. While object data is stored in ordinary 
MS-DOS files, filenames are controlled by the OMF, not 
by the user. When the OMF starts an application program, 
it passes the MS-DOS file specification for the location of 
the application's data. The actual filenames are controlled 
by the OMF, and while known by the application, are never 
displayed to the user. This frees the user from the details 
of the MS-DOS file system, and allows the use of meaning- 
ful titles to identify individual objects. More important, it 
allows the user to create, copy, move, and mail compound 
objects, which are made up of multiple files, without wor- 
rying about creating individual names and resolving nam- 
ing conflicts and collisions among the files. 

For many applications it may require multiple files to 
store the information that makes up a specific object. For 
example, a data base application may require a form specifi- 
cation file, an index file, and the actual data base file to 
describe a data base completely. To accommodate this 
need, the OMF passes the application a fully qualified root 
filename (first eight characters with no extension) to specify 
the location of the OMF-managed data. Using the root 
filename, the application can create multiple files with 
different extensions, or even create nested subdirectories. 
The OMF will properly recognize all files in the nested 
structure when manipulating the object's data. 

When encapsulating an unmodified MS-DOS applica- 
tion, it is often impossible to shield the user from all the 
details of the file system. For many applications, important 
functions, such as merging data, saving subsets, linking 
macros or scripts, translating files, or accessing individual 
files that make up the entire data set, depend on the user's 
specifying the MS-DOS filename. The encapsulation facil- 
ity cannot hide these filenames from the user without se- 
verely limiting the capabilities of the application. Instead, 
the encapsulation facility must allow the user to specify 
the MS-DOS filenames used for each data instance and 
treat them as if they were the data files assigned and man- 
aged by the OMF. Resolving this dichotomy between the 
MS-DOS and OMF environments presents the biggest 
single challenge (and limitation) of encapsulation. 

Since encapsulated applications rely on the MS-DOS file 
system to store and retrieve data, the user must specify a 
valid MS-DOS filename when creating a new encapsulated 
object. A complete MS-DOS file specification is made up 
of several parts (see Fig. 4). To simplify this process for 
the user, the encapsulation facility assigns a default sub- 
directory for each encapsulated application class. The user 
need only specify the eight-character root filename and the 
encapsulation facility provides default values for the drive 
and path of the assigned subdirectory as well as the pre- 
defined default file extension for the selected encapsulated 



application class. The appropriate template file (or files) 
is copied to the default subdirectory and the newly created 
object references this file instead of the file the OMF would 
automatically assign for a true NewWave application. An 
error will be indicated if the user does not specify a valid, 
unique filename. 

Fig. 5 shows the directory organization for a typical New- 
Wave system with encapsulated applications installed. 
There are three directories managed by the NewWave envi- 
ronment as well as other directories for application programs 
or user data unrelated to the NewWave environment. The 
OMF maintains the HPNWPROG directory for all NewWave 
executable programs and the HPNWDATA directory contains 
all the NewWave object data files as well as the OMF data 
base. To improve file access performance, the OMF auto- 
matically creates multiple subdirectories within HPNWDATA 
as required. There is rarely any reason for the user to directly 
access the files in the HPNWPROG or HPNWDATA directories. 
The encapsulation facility maintains the HPNWDOS direc- 
tory which contains the data files for encapsulated applica- 
tions. Each encapsulated application class is assigned its 
own subdirectory within the HPNWDOS directory and the 
filenames within these subdirectories are those assigned 
by the user when the encapsulated objects were created. 
By means of this well-defined directory structure, the user 
can locate and manipulate encapsulated data files even 
when the HP NewWave environment is not active. Since 
each encapsulated application may have its own specific 
requirements for how its executable program files are or- 
ganized within a directory, the encapsulation facility does 
not attempt to manage these files directly. An encapsulated 
application program is installed on the system in its normal 
manner and the encapsulated application class definition 
provides the necessary information for the encapsulation 
facility to locate and access the application. This also al- 
lows the application to be accessed even if the HP New- 
Wave environment is not active. 

The encapsulation facility also supports references to 
files that already exist in the MS-DOS file system, files 
outside the default subdirectory, and an entire subdirectory 
of encapsulated data. The specific details of these facilities 
go beyond the scope of this article and are not necessary 
to understand the basic operation of encapsulation. 

Once the MS-DOS file is encapsulated the user is free to 
move or share the object representation of the file anywhere 
within the OMF domain. It can reside in the NewWave 
Office, or be placed in any level of nested folders. Even 
though the object representation is moved within the OMF, 
the same MS-DOS file reference originally assigned by the 
user is still maintained. As with OMF data files, this 
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filename may represent multiple files with different exten- 
sions, or a subdirectory structure of arbitrary complexity. 
The root filename is always displayed in place of the ob- 
ject's title. To minimize clutter on the screen, only the 
eight-character base portion of the filename is displayed 
by default. However, if the user selects this filename field 
for any specific object, the complete, fully qualified MS- 
DOS file specification is displayed. 

Whenever the user copies or imports an object, a new 
file must be created. This happens transparently for OMF 
objects, since the OMF assigns the new filename. However, 
a new file cannot be created for an encapsulated object 
until the user provides a valid new filename. In many cases, 
this is simply not practical at the time the copy operation 
is performed. For example, when new mail arrives via an 
electronic mail system, objects and their associated files 
must be created to receive the incoming information. But 
at that time the user has no idea exactly what is being 
received, and therefore cannot intelligently decide what 
the filenames should be. Likewise, when copying a folder 
object that contains dozens of encapsulated objects in sev- 
eral levels of nested folders within it, it is not practical to 
expect the user to provide all the needed filenames. It 
should be equally obvious that it is simply not acceptable 
to prevent the user from copying, importing, or mailing 
encapsulated objects. The filename of the source object 
cannot be used without fear of collision with existing files. 

The encapsulation facility solves this problem by recog- 
nizing that the data does not actually have to be in an 
MS-DOS file known to the user until the user is ready to 
open the object. Therefore, whenever an encapsulated ob- 



ject is copied, imported, or received via mail, the encapsu- 
lation facility allows the OMF to assign a filename for the 
copy. Rather than display this filename as the title (which 
would be meaningless to the user) it displays the string 
Copy of: followed by the eight-character root filename of the 
original object. The user can move, copy, share, delete, or 
mail this copied object, and the OMF will manage the as- 
sociated data file as it does for any other object. The first 
time the user opens the object, the encapsulation facility 
will prompt the user for the required filename. Before start- 
ing the encapsulated application, the data is moved from 
the OMF-maintained file to the file identified by the user, 
and the object title is changed to reflect this new filename. 

While this approach does have some limitations, it pro- 
vides a practical method for encapsulated applications to 
behave like other HP NewWave objects, while still being 
able to access data using the MS-DOS file system. 
Automatic Object Creation. A common feature of many 
applications is the ability to save data in a new file while 
the application is active. This allows the user to create 
multiple files, saving the current data in a new file and 
then continuing to make changes. In this case, the applica- 
tion itself is creating the data file, not the encapsulation 
facility or the OMF. But since the user expects the newly 
created file to appear as a new encapsulated object, the 
encapsulation facility monitors the creation of new files, 
and automatically creates an associated object with the 
required file reference. 

Because of the difficulty of monitoring the internal oper- 
ations of the MS-DOS file system, the encapsulation facility 
performs this automatic registration by comparing the con- 
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tents and date stamps of files in the default data directory 
before and after the encapsulated application is run. This 
search-and-compare operation is limited to the default data 
directory for the encapsulated object class, primarily for 
performance reasons. 

Many applications are also able to create files compatible 
with other applications, for example, a spreadsheet that 
can store information in a form compatible with a data 
base program. In the case where both applications are en- 
capsulated in the HP NewWave environment, the encapsu- 
lation facility can be configured to allow one application 
class to create objects of the other class, referencing the 
newly created files. 

In some cases, applications specifically written for the 
HP NewWave environment provide a facility to convert or 
import information from MS-DOS files. The encapsulation 
facility can be configured to access this feature program- 
matically, providing a method to create the appropriate HP 
NewWave object automatically from information created 
by an encapsulated object. 

Menus and Macros. While the encapsulation facility sup- 
ports many automatic procedures, it may often require a 
less-than-intuitive sequence of steps within the encapsu- 
lated application to take advantage of it. For example, in- 
itiating an automatic conversion to an HP NewWave appli- 
cation requires saving the file in a predefined location, 
allowing the encapsulation facility to locate it easily. To 
make this feature easily available to the user, the encapsu- 
lation facility provides a method to create new pull-down 
menus for the encapsulated application. A keystroke macro 
is associated with each menu command and executed when 
the command is selected by the user. These macros can 
contain instance-specific, class-specific, or system-wide 
global variables. 

For Microsoft Windows applications, these menu com- 



mands are added to the existing application menus. Micro- 
soft Windows provides the programmatic facility to change 
menu configurations dynamically. By intercepting and fil- 
tering all Microsoft Windows messages received by the 
encapsulated application, the encapsulation facility can 
detect when one of its new menu commands is selected, 
and respond by sending a series of messages to the appli- 
cation that simulate the associated macro being entered via 
the keyboard. 

For full-screen applications, the encapsulation facility 
monitors the interrupt service routines used to manage the 
keyboard. When the appropriate activation key is detected, 
the added menu commands overlay the full-screen applica- 
tion's display. The keyboard interrupt service routine is 
monitored to determine what menu command is selected, 
and the appropriate macro is sent to the application through 
the interrupt service routine, simulating keyboard input. 

Configurable menus and keystroke macros offer a power- 
ful mechanism for extending the user interface of encapsu- 
lated applications, and provide an easy way for the user 
to access the additional features provided by the encapsu- 
lation facility. 

Agent Support. The encapsulation facility provides key- 
stroke recording and playback to extend the functions of 
the agent facility to support encapsulated applications. 
This is implemented using the same windows message or 
keyboard service interrupt filtering used for the configura- 
ble menu and macro feature. While this solution is not 
without significant limitations, it does provide the basic 
capabilities required to automate system-wide tasks that 
also include encapsulated applications. 
Configuration Parameters. Generic encapsulation supports 
a wide variety of applications, using a sequence of config- 
uration parameters to provide the detailed information re- 
lated to each program. Following are some of the parame- 
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ters that provide the generic encapsulation facility with 
the information it needs to know about the application 
being encapsulated. 

■ Application Type. Specifies whether the encapsulated 
application is a Microsoft Windows application or a full- 
screen application. 

■ File Access Method. Specifies whether data for this ap- 
plication will be stored in referenced MS-DOS files, or 
in OMF-controlled files. The latter are useful when the 
encapsulated application can be modified to remove de- 
pendencies on users to specify the filenames for data 
files. 

■ Application Name. The subdirectory location and name 
of the encapsulated application. 

■ Command Line. The command line parameters to be 
passed to the application when it is started. This is the 
most common method for providing the instance-spe- 
cific filename to the application. 

■ Current Directory. The drive and subdirectory that 
should be selected as the current directory before the 
application is started. Some applications require that the 
directory containing the main program be the current 
directory. For others, making the default data directory 
the current directory eases access to additional data files. 

■ Menu File. The name of the optional file that defines 
the added menu commands and their associated key- 
stroke macros. 

■ Window Class. For Microsoft Windows applications, 
this specifies the indentifier used by Microsoft Windows 
to identify the application's window type. 

■ Window Title. The text identifier maintained by Micro- 
soft Windows that identifies a window and is displayed 
in the window's title bar. This field and the preceding 
one are used by the encapsulation shell to locate the 
application's window when it is initiated. The location 
is needed to configure menus and macros and filter the 
application's messages. 

■ Key Extension. The three-character filename extension 
(e.g., .GAL for Drawing Gallery files) that is searched for 
to determine if new files for the application have been 
created and need to be automatically registered. The key 
extension is also used for error and filename collision 
detection when the user provides new filenames. 

■ Required Extensions. Specifies the extensions of other 
files that must be present to make up a valid data in- 
stance. This is also used for error and filename collision 
detection. 

■ Data Directory. The default data directory for the appli- 
cation. This is where all files for this application class 
are typically stored. 

■ Export Classes. Specifies the classnames of other encap- 
sulated applications that may be created by this applica- 
tion. 

■ Conversion Classes. Specifies the classnames of HP New- 
Wave applications that support programmatic conver- 
sion and can be accessed by this application. 

These and other configuration parameters are specified 
when the encapsulated application class is installed in the 
HP NewWave environment. They are stored as text in the 
class properties for the application, and can therefore be 
programmatically accessed by any other application that 



needs this information. Like the configurable keystroke 
macros, the configuration parameters can include a variety 
of instance-specific, class-specific, or global system vari- 
ables, providing a tremendous degree of flexibility. Using 
variables, any text property of any other application class 
can be accessed. Because the OMF property system is ex- 
tensible, developers can specify additional properties and 
access this information as configuration information or key- 
stroke macros from multiple, cooperating applications. 

Application-Specific Encapsulation 

While generic encapsulation makes it possible for many 
applications to operate as part of the HP NewWave environ- 
ment, it does not support one of the most important capa- 
bilities: views. For applications to share data cooperatively, 
the encapsulation facility must not only know how to com- 
municate with other applications, but must also under- 
stand and be able to modify the application's data structure. 
It must also provide additional commands and dialogs to 
manage the links that are created. This invariably requires 
the development of a specialized encapsulation program 
that recognizes the specific features and data formats of 
the application it encapsulates. The solutions are as varied 
as the applications that can be encapsulated. With enough 
effort invested in the encapsulation shell, virtually all HP 
NewWave capabilities can be supported. But this process 
may entail more effort than simply rewriting the applica- 
tion for the HP NewWave environment. 

To encapsulate Lotus 41 ' 1-2-3®, a spreadsheet program 
from Lotus Development Corporation, an HP NewWave 
browser application was developed (see Fig. 6). This pro- 
gram reads the Lotus 1-2-3 spreadsheet data file, displaying 
its contents in the Microsoft Windows environment. The 
encapsulation browser provides the necessary user com- 
mands and interfaces to the OMF to allow ranges of the 
Lotus 1-2-3 worksheet to be viewed in other HP NewWave 
applications. To minimize the browser's complexity, it is 
only capable of reading the Lotus 1-2-3 worksheet file; it 
cannot make changes to it. Instead, the browser provides 
a command to start the Lotus 1-2-3 program., automatically 
loading the data file being browsed. When the user exits 
from Lotus 1-2-3, the updated file is redisplayed by the 
browser. Because the browser does not alter the spreadsheet 
data, it will not accept data passing views* from other 
applications. A similar browser-type encapsulation shell 
was developed for HP Graphics Gallery. 

Conclusion 

HP NewWave's encapsulation services provide the 
bridge from today's MS-DOS-based applications to the next 
generation of applications developed for the HP NewWave 
environment. The DOS programs service and generic en- 
capsulation provide the facilities for users to take advantage 
of HP NewWave immediately, while continuing to use their 
current suite of applications. Application-specific encap- 
sulation provides an interim solution to allow developers 
to move their existing applications into the HP NewWave 
environment and take advantage of its advanced features 
without requiring a complete application rewrite. The HP 

"A data passing view is a data link between objects that allows the child to pass data to 
the parent. 
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NewWave environment clearly defines the applications en- 
vironment of the future, and the complete range of encap- 
sulation services provides a clear, well-lighted path for 
today's personal computer users. 
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the Personal Software Divi- 
sion, Barbara Packard's 
NewWave assignments in- 
cluded NewWave agents 
and task language compil- 
ers. She came to HP in 
1973 and spent seven 
years working on the 
COBOL compiler and 
COBOL toolset for the HP 3000 Computer, partly 
as project manager. She also served as project 
manager for a cross-Pascal compiler and 
MemoMaker software developments. Before com- 
ing to HP, Barbara was an aeronautical research 
engineer for the U.S. National Aeronautics and 
Space Administration. Her BS degree in mathe- 
matics is from Stanford University (1 954), as are her 
two master's degrees, one in mathematics (1 955) 
and one in computer science/computer engineer- 
ing (1977). She is a member of the ACM and the 
American Association for Artificial Intelligence. 
Barbara was born in Orange, California, and lives 





43 = NewWave Help Facility 
Vicky Spilman 

As a software engineer at 
the Personal Software Divi- 
sion. Vicky Spilman worked 
on the help system for the 
NewWave environment. 
She came to HP in 1982. 
soon after graduating from 
California State University 
?*L, at Chico with a BS degree 
■mm in computer science. In the 
past. Vicky has been involved with graphics sys- 
tems and independent-software-vendor products 
as a support engineer and has worked on software 
for the HP 150 Personal Computer. Vicky lives in 
Sunnyvale, California, and enjoys gardening, 
aerobics, and bicycling. 



Eugene J. Wong 

Eugene Wong was project 
manager for the NewWave 
help facility, formatter, 
builds, and system perfor- 
mance and installation. He 
also served as system 
manager for the NewWave 
developer system. In past 
assignments, he has 
served as engineer and as 
project manager for automatic test systems and 
real-time systems. He also managed the develop- 
ment of third-party software ports to the HP 1 50 Per- 
sonal Computer Eugene's BA degree in mathema- 
tics is from San Francisco State College; he came 
to HP after receiving his degree in 1970. He is a 
member of the ACM and the IEEE. The HP 1000 
RTE-IV operating system is the subject of a previ- 
ous article he has written for the HP Journal. 
Eugene was born in Stockton, California, and lives 
in Cupertino, California He is married and has two 
daughters. In his off-hours, he likes to play go. read, 
and study medieval calligraphy. 




48 Computer -Based Training 

Lawrence A. Lynch-Freshner 

A software engineer as- 
signed to the NewWave 
project, Larry Lynch-Fresh- 
ner focused his attention on 
design and implementation 
of the animation and com- 
puter-based training dis- 
play functions. In projects 
before he joined the Per- 
sonal Software Division, he 
supported the operating systems for HP 150 and 
HP Vectra PCs. He studied computer science at 
Oregon State University and came to HP in 1 983. 




He is a member of the ACM. SIGPLAN, and SIG- 
GRAPH. and his professional interests include 
computer languages, computer graphics, and win- 
dowing systems Larry has served in the U.S. Air 
Force Reserve. He was born in Salem, Oregon, and 
makes his home in Mountain View. California. He 
is married and has a son. Among his many avoca- 
tions are beer brewing, ancient history and an- 
cients war-gaming, electronics, robotics, science 
fiction, and jewelry-making. 



R. Thomas Watson 

As software development 
jUB^^ engineer. Tom Watson was 
jf'MNB/tk ^sponsible for the agent 
j facility for computer-based 

W W> training, and he continues 

to be involved with New- 
Wave development. His 
past professional experi- 
ence includes positions as 
computer sales manager 
and as computer programmer He came to HP in 
1 984. His BS degree in computer science is from 
Pennsylvania State University. He is a member of 
the ACM . Tom was born in Upper Darby, Pennsyl- 
vania, is married, and lives in San Jose, California. 
His after-hours interest is synthesized music. 



John J. Jencek 

The most recent addition to 
^jjjBffl^ the NewWave CBT de- 
I velopment team, John 

Jencek joined HP in June 
1988 as a software en- 
gineer. The computer- 
based training software was 
his first assignment. He de- 
veloped the parsers and the 
CBT menu object and con- 
tinues to work on NewWave design objectives. His 
previous experience includes work as computer 
programmer at IBM Corporation and as instructor at 
Texas Instruments John was born in Prague, 
Czechoslovakia He attended the California State 
University at San Francisco, where he earned his 
BS degree in computer science (1 988) He lives in 
San Francisco. California, and enjoys scuba diving 
in his off-hours. 



Brian B. Egan 

Brian Egan is product man- 
ager for interactive learning 
systems at HP's Personal 
Software Division. His role 
in the development of the 
NewWave environment 
was that of manager and 
editor of the computer- 
based training software 
and courseware. His past 
positions include publications manager, support 
manager, and customer engineer, His professional 
interests focus on computer-based and classroom 
instruction, user interfaces, and teaching. Brian's 
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BS degree m computer science engineering is from 
California State University at San Jose, earned after 
seventeen years of attending night school. He 
served seven years in the U .S. Air Force, where he 
was a technician and instructor in metrology. He 
was born in New York City, is married, and has two 
children. Brian lives in San Jose, California. As an 
avocation, he teaches writing classes for engineers 
al California State University. He also likes hiking 
and mountain bicycling, and plays bass guitar in 
a rock band 




57 — Encapsulation of Applications 

William M. Crow 

As an R&D proiect man- 
ager on the NewWave proj- 
ect, Bill Crow was respon- 
sible for OMF and Office 
software and the generic 
encapsulation. He con- 
tinues to serve as project 
manager on other New- 
Wave assignments He at- 
tended the University of 
Vermont where in 1 974 he received his BS degree 
in mathematics. He joined HP's Personal Software 
Division in 1984, where his responsibilities in- 
cluded the development of graphics products for 
the HP 3000 Computer. Bill's past professional ex- 
perience includes positions as director of com- 
puter systems at The Austin Company and as soft- 
ware designer for an aerospace company He has 
authored numerous papers and articles about data 
communications, office automation and personal 
computers. He is named comventor in two patents 
relating to navigational systems and three pending 
patents on the NewWave environment. Bill was 
born m Newark, New Jersey, is married, and lives 
in San Jose, California. His major hobby is personal 
computers. 




67 Tape Drive Design 

Andrew D. Topham 

Tape head and cartridge 
technology were Andy 
Topham's focal points as 
an R&D engineer on the HP 
9145A project. He has 
been a manufacturing en- 
gineer on a similar product, 
the HP 9144A, and is now 
responsible for a new prod- 
uct involving a tape drive. 
Before he joined HP in 1 985, he worked for Racal 
Research Ltd. as an R&D engineer for digital signal 
processing and for Research Machines Ltd. on the 
design of microcomputers. The tape head mount- 
ing system described in this issue of the HP Journal 
is the subject of a pending patent that names Andy 
as a coinventor He obtained his degree in physics 
at the Imperial College m London in 1981 and is an 
associate member of the IEE. Born in Birmingham, 
he now resides in Dursley, Gloucestershire. He is 
married and has an infant son. His hobbies include 
boardsaihng, gardening, running, and photo- 
graphy. 




74 "Tape Drive Reliability Z^ZZ^^^H 
David Gills 

For over four years, Dave 
Gills has been a reliability 
engineer and has worked in 
both R&D and quality con- 
trol departments in HP's 
Bristol facility. He was the 
project reliability engineer 
for the HP9145A and has 
since moved to a new di- 
gital audio tape project His 
past assignments include the HP. 35401 A Cartridge 
Tape Drive. In his earlier career, Dave was a range 
and flight trials engineer working on guided 
weapons for the British aerospace company Some 
years before graduating from Coventry Polytechnic 
with a BSc degree in 1 983, he served a four-year 
mechanical-engineering apprenticeship with ICI 
Fibres Ltd. He is an associate member of the Insti- 
tute of Mechanical Engineers and a member of the 
Safety and Reliability Society Dave was born in 
Cheltenham, is married, and has an infant son. He 
lives in Dursley, Gloucestershire Golf is his favorite 
pastime. 



82 Real-Time Peripheral Firmware 

Tracey A. Hains 

As an R&D engineer on the 
HP 9145A, Tracey Hains' 
responsibilities included 
analysis, design, and de- 
velopment of firmware for 
the device task and the 
operating system. She has 
since begun designing the 
digital data storage format 
for new products. Other as- 
signments Tracey has worked on include the de- 
sign of software for a networked backup product. 
She came to HP in 1985, after receiving her BSc 
degree in mathematics and computer science from 
the University of Bristol. A pending patent de- 
scribes algorithms Tracey originated. She was 
born in Dorset, is married, and lives in Bristol. 



Mark J. Simms 

Design, test, and debug- 
ging of the buffer manage- 
ment software for the HP 
9145A Cartridge Tape 
Drive was Mark Simms' re- 
sponsibility. A software en- 
, gineer at the Computer 
Peripherals Bristol facility, 
his cognizance now in- 
cludes the overall analysis 
and architectural design for other tape drives and 
the design of buffer management software In past 
assignments, he was responsible for the data 
spooling software used in earlier products Two 
patents are based on Mark's ideas, one for remote 
backup software and another for a file system 
search method. He received his BSc degree m 
computer science/mathematics from Bristol Uni- 
versity in 1 984, the same year he joined HP. Born 
in Leeds, he is married and lives in Bristol. 






Paul F. Bartlett 

As an R&D software quality 
| engineer, Paul Bartlett was 
responsible for the design, 
implementation and testing 
of the HP-IB interface han- 
dling process used with the 
HP 91 45A. He is now work- 
ing on the development ol 
a process aimed at assur- 
ing quality and reliability of 
firmware design. Before coming to HP in 1 985, Paul 
designed telephone switching systems software 
for C.E.C. Telecommunications and software for 
mobile radio applications for Pye Telecommunica- 
tions. He is named inventor m a pending patent de- 
scribing algorithms used in remote backup soft- 
ware. Paul received his BSc degree in mathematics 
from the Imperial College in 1977, and he is a 
member of the British Computer Society. He was 
born in Aldershot and lives in Bristol, the home of 
HP's computer peripherals facility. He's married 
and has three children, a boy and twin girls. His 
hobbies include bicycling and photography. 



Paul F. Robinson 

As one of the project man- 
jfiltifllL agers for :he HP 9145A 
Cartridge Tape Drive, Paul 
Robinson was responsible 
for firmware development, 
n a previous assignment, 
he worked as an R&D en- 
gineer on a cost reduction 
project. Before joining the 
HP Computer Peripherals 
Bristol Division in 1 985, he designed CAD software 
for a number of electronics companies, among 
them Phillips and Racal Corporations Paul studied 
computer science at the Loughborough University 
of Technology and is a member of the British Com- 
puter Society. His professional interests focus on 
software methods, metrics, and R&D processes. 



L 




87 Object-Oriented Software Technology ~ 

Thomas F. Kraemer 

Tom Kraemer was the proj- 
ect manager of the HP Vista 
software development at 
HP's Lake Stevens facility. 
He has contributed to the 
development of many HP 
calculator, computer, and 
instrument products as an 
engineer, project manager, 
and section manager. Cur- 
rently a section manager in HP's Logic Systems 
Division, he is responsible for R&D on HP Team- 
work SA/SD and HP 64700 emulator products. Tom 
joined HP in 1 978. after earning his MSEE degree 
from Oregon State University, where he also 
worked on a U S Navy research program Before 
starling college, he was a professional animator 
and became interested in applying computer tech- 
nology to animation He is married and resides in 
Sunnyvale, California, 
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Mechanical Design of a New Quarter-Inch 
Cartridge Tape Drive 



The design of the HP 91 45 A Tape Drive required doubling 
both the track density and the tape speed of the existing 
HP 91 44 A, thereby doubling the older drive's 67 -Mbyte 
capacity and 2-Mbyte-per-minute transfer rate. 

by Andrew D. Topham 



THE EVER-INCREASING VOLUMES OF DATA being 
handled by computer systems make it mandatory 
for backup tape devices to continue to match the 
growing disc capacities being projected. Both data trans- 
fer rate and tape cartridge capacity must continually be 
improved. 

The HP 9145A Vi-Inch Cartridge Tape Drive (Fig. 1) was 
developed in response to this need. Before the HP 9145A 
was developed, HP's entry level and midrange commercial 
computer systems and technical workstations were usually 
configured with either an HP 91 44 A Tape Drive or an HP 
35401 A Autochanger for backup, depending on disc capac- 
ity. The HP 9144A has a cartridge capacity of 67 Mbytes 
and a data transfer rate of 2 Mbytes per minute. The au- 
tochanger uses the same mechanism and has the same 
transfer rate, but achieves a capacity of 536 Mbytes by 
changing eight tape cartridges without operator attention. 

The HP 9145A provides full compatibility with the HP 
9144A and the HP 35401A while also providing twice the 
data transfer rate. This is achieved by doubling the tape 
speed from 60 to 120 inches per second. As a result, users 
can back up their systems in half the time. 

The HP 9145A has twice the data capacity per cartridge 
of the HP 9144A. This is achieved by doubling the number 
of recording tracks from 16 to 32. The HP 9145A can read 
the older 16-track tapes, but the older drives cannot read 




Fig. 1. The HP 91 45 A 'A-lnch Tape Drive provides a storage 
capacity of 133 Mbytes per cartridge and a data transfer rate 
of 4 Mbytes per minute for backing up disc memory in entry 
level and midrange computer systems. 



the new 32-track tapes. 

Technical Challenges 

When the development team started the task of designing 
the HP 9145A, there were several key areas where major 
design changes were required. 

Mechanical Design. To achieve the increased capacity, the 
number of tracks across the tape width had to be doubled 
within the same 'A-inch tape width. To achieve the in- 
creased data transfer rate, the tape speed had to be doubled. 
The design had to accommodate variations in components, 
manufacturing processes, and operating environments and 
remain capable of accurately positioning the read/write 




Fig. 2. Exploded view of the new HP 92245US cartridge. 
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head within the data tracks to guarantee data reliability. 
New Cartridge. An improved cartridge design had to be 
introduced to support the increased tape speed and capac- 
ity requirements. This implied complete qualification and 
testing as well as the setup of formatting and certification 
lines by the cartridge manufacturers. At the same time, to 
maintain compatibility, the drive design had to guarantee 
that HP 9144A-written tapes could be read. The new car- 
tridge features an improved mechanical design and new 
tape media. The tape offers higher reliability with a new 
oxide formulation, which reduces the signal decay that 
occurs each time the cartridge is used. The cartridge has a 
new belt and corner rollers to accommodate the increased 
tape speed, and an extra tape guide for better read/write 
accuracy. 

Increased Reliability. The HP 9145A had to satisfy the user 
needs that had been identified. This required designing to 
much tighter tolerances and higher performance. At the 
same time, we had to ensure that the new product incorpo- 
rated the lessons learned from the existing line and product 
range with regard to reliability and manufacturability. Re- 
liability issues are discussed in the article on page 74. 
Time to Market. To meet market needs, reliable prototypes 
of the HP 9145A had to be ready for testing with the target 
computer systems in under 12 months. Thus the design 
team had less than a year to design hardware and firmware 
from concept to reliable implementation. 



the tape path and servo interface are closely aligned. The 
drive takes advantage of this by clamping the baseplate 
against accurately defined stops within the mechanism. 
This ensures that the tape path aligns precisely with the 
tape head magnetic cores used to read data from and write 
to the tape, and that the servo motor puck aligns with the 
drive roller within the cartridge. 

Sixteen tracks of data are written across the quarter inch 
of tape width. To read and write each of these tracks inde- 
pendently, the tape head in the drive is driven vertically 
by a stepper motor and leadscrew arrangement. 

HP 9145A Improvements 

Because the development cycle had to be short and the 
HP 9144A design offered a good starting point for many of 
the design requirements, it was decided to leverage off this 
product as much as possible. This approach was particu- 
larly pronounced in the mechanism area where, for exam- 
ple, the casting used to align all the mechanical compo- 
nents and the cartridge clamping assembly were left totally 
unchanged. Fig. 3 shows the HP 9145A drive mechanism 
with its associated electronics removed. 

The development of an enhanced V^-inch cartridge from 
the cartridge manufacturer, dubbed the HP 92245L/S, made 
possible the doubling of the track density. Evaluation of 
this cartridge was in itself a major task which was run in 
parallel with the drive development. 



HP 9144A Design 

The HP 9144A Tape Drive's tape transport mechanism 
has design concepts common to all '/4-inch cartridge tape 
drives. The cartridge itself (Fig. 2) provides a reference 
plane in the form of the cartridge baseplate against which 



Tape Speed 

The HP 9144A data transfer rate was identified as a prior- 
ity area to be improved upon. With the HP 9145A providing 
double the cartridge capacity, keeping the data transfer rate 
constant would have resulted in a doubling of the time for 




Fig. 3. HP 9145 A drive mecha- 
nism. 
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reading or writing a cartridge. 

One approach that could have been taken would have 
been to increase the linear transition density of the data 
on the media, resulting in a correspondingly higher data 
rate for a constant tape speed. However, this was rejected 
for two reasons. First, it would have led to complications 
in the read channel filtering and data recovery side of the 
drive, because of the need to continue to be able to read 
HP 9144A data with its lower transition density. Second, 
the media had not been proved able to perform sufficiently 
well at the higher transition density. The cartridge man- 
ufacturer was actively evaluating the media for this density, 
but there would inevitably have been an increased risk to 
the project. 

The approach taken to improve the data transfer rate was 
to double the tape speed while keeping the transition den- 
sity the same as in the HP 9144A drive. This led to a twofold 
transfer rate improvement, and took the drive from the 60 
ips (inches per second) used by the HP9144Ato 120 ips. 

Running the tape at this speed raised some technical 
concerns about the cartridge. Would the mechanics of the 
cartridge be able to handle this speed without either in- 
stabilities in the tape transport or degradation of cartridge 
operating lifetime? Would an air bearing form between the 
head and the tape, causing signal loss? 

Cartridge Mechanics 

The new HP 92245L/S cartridge was developed by the 
cartridge manufacturer with one of its major goals being 
continuous, reliable operation at a tape speed of 120 ips. 
During the testing of the HP 9145A drive the design team 
was able to provide valuable feedback to the cartridge man- 
ufacturer on the performance of the cartridge, with the 
result that several design modifications were made to boost 
the long-term reliability. 

Critical parameters in the cartridge evaluation were the 
tape tension, the drive force, and acoustic noise. The tape 
tension had to be high enough to prevent the formation of 
an air bearing between the head and the tape, and yet low 
enough to prevent excessive head wear and hence short 
drive lifetimes. The drive force (the drag applied by the 
cartridge on the servo motor) had to be sufficiently low 
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that the servo drive motor and associated control elec- 
tronics that control the tape speed at 120 ips were not 
unduly stressed. Doubling the tape speed was found to 
have a substantial effect on the audible noise emitted from 
the cartridge. The HP 9144A and HP 9145A drives are 
bound by the HP specification for office environment oper- 
ation and so have to satisfy a very low noise requirement. 
A joint development program, with the drive design team 
supplying test data to the manufacturer concerning the 
noise emissions from the cartridge in the HP 9145A drive, 
allowed the cartridge manufacturer to modify the cartridge 
to bring the noise level down to an acceptable level (Fig. 4). 

The overall result of the work that went into solving all 
the above problems was that the HP 92245L/S cartridge 
has emerged as a substantial improvement over its pre- 
decessor. Many of the changes that have been implemented 
in the HP 92245L/S cartridge are now being adopted for 
the HP 9144A cartridge. 

There was concern whether older cartridges used in HP 
9144A drives could be read in the HP 9145A drive. These 
had only been rated at a maximum tape speed of 90 ips by 
the cartridge manufacturer. However, an extensive testing 
program during the development of the HP 91 45 A drive 
confirmed initial indications that these cartridges were 
very conservatively rated, and the majority performed well 
in the test program. In a very small number of cases there 
was some cause for concern over the longer-term use of 
such cartridges at 120 ips. An unacceptable increase in 
drive force could occur after running continuously for sev- 
eral days at the maximum rated operating temperature. 
This problem was avoided by specifying that the new drive 
would only be required to offload data from an HP 9144A 
cartridge once. This is backed up by instructions to this 
effect in the user manual. 

Head-to-Tape Contact 

Intimate contact between the tape head and the media 
is essential in any tape drive to provide maximum read 
signal and minimum distortion. Head-to-tape contact is 
dependent on three factors: 

■ Tape speed. A higher speed produces greater spacing. 

■ Tape tension. Higher tension pulls the tape closer to the 
head. 
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Fig. 4. Noise level of the new HP 92245US cartridge com- 
pared with its predecessor. 



Fig. 5. Steady-state tape tension of the HP 92245L/S data 
cartridge, comparing the improved textured drive belt with 
the standard belt used in older cartridges. 
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3 Head profile. The shape of the front face of the head in 
contact with the tape has a complex effect on the tape 
spacing. 

The development program for the HP 92245L/S cartridge 
resulted in that cartridge having such an excellent tape 
tension characteristic that head-to-media separation is not 
a problem, even at 120 ips (Fig. 5). 

The testing program showed that for the vast majority of 
the older HP 9144A cartridges, there was no problem in 
running at 120 ips. A very small number of exceptions to 
this rule were found. The problem cartridges were from a 
few batches that the cartridge manufacturer was able to 
trace back to a time when there had been minor problems 
in the cartridge production process. These cartridges exhib- 
ited very low tape tension so that, at 120 ips, there was a 
tendency for the tape to lift off the read/write head slightly. 
This led to reduced read signal amplitude (spacing loss) 
and so occasionally to read errors. 

One attempt to keep the spacing loss to a minimum was 
through experimenting with the tape head profile. This 
profile must be accurately designed and machined to offer 
a surface that does not abrade the media, will withstand a 
lifetime's use, and maintains intimate contact with the 
media. The wear requirement and the intimate contact re- 
quirement tend to favor opposing profile shapes, so that 
any solution is inevitably a compromise between the two. 
Some experimentation with profiles that exhibited radii 
both sharper and more gentle than that used on the HP 
9144A tape head showed that the existing profile, as shown 
in Fig. 6, was a good approximation to the ideal. The adop- 
tion of this profile removed another risk area in that this 
profile is already well-understood and in large-scale pro- 
duction. 

The spacing loss problems were overcome by building 
into the drive a 90-ips read mode option. Dropping the 
speed causes the tape to drop closer to the head, thereby 
improving the read signal. This option is automatically 
invoked by the drive when it detects that errors are occur- 
ring because of the above phenomenon. Extensive testing 
has proved the capability of this approach. 




Fig. 6. HP 9145 A (ape head profile. 



Track Density 

The HP 9 144 A drive places 16 tracks across a Vi-inch 
media width. To double the capacity of the drive without 
increasing the linear bit density it was necessary to fit 32 
tracks across the media. This was achieved by: 

■ Reduced written track width 

■ Improved head positioning accuracy 
Improved cartridge tracking specifications 

m Improved cartridge media defect specifications 

■ A new track layout 

■ Track seeking 

Q Improved core alignment 

: Improved tape head mounting. 

Track Width. The track width of a tape drive is defined 
by the width of the magnetic core within the tape head. 
Both the HP 9144A and the HP 9145A use a system of wide 
write, narrow read, whereby the read core width is less 
than the width of the written track. This ensures that the 
read core will be over the written track even if there are 
positional errors between the core and the center of the 
track (Fig. 7). If the read core falls outside the written track, 
the signal amplitude from the track will be reduced and 
the core may also pick up the remains of previously written 
data. This would degrade the drive's signal-to-noise ratio 
and compromise its recovery capability. 

The track width specified for the HP 9145A drive is, as 
far as we know, the narrowest used in the industry on 
V^-inch cartridges, and is about half that in the HP 9144A 
drive. To achieve this we need to hold the tape head core 
width and core alignment tolerances tighter than in any 
comparable head. This was achieved by working very 
closely with the tape head vendor to refine their existing 
HP 9144A head manufacturing process until it was capable 
of producing HP 9145A heads with consistently good 
yields. In a year the vendor went from doubting that 
adequate yields could ever be achieved to producing heads 
that fully met the specification with good yields. 
Head Positioning Accuracy. Head positioning to select be- 
tween tracks in the HP 9144A drive is achieved by a stepper 
motor driving a lead screw. Riding up and down the lead 
screw is the head carrier assembly with the tape head 
mounted at one extreme. 

This approach was maintained for the HP 9145A. How- 
ever, the resolution of the stepper had to be at least doubled 
to place the head accurately over tracks that were half as 
far apart. Stepper motors with small angular stepping incre- 
ments are now fairly common. However, the real challenges 
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Fig. 7. Misalignment error. 
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here proved to be obtaining a leadscrew that maintains a 
constant thread pitch along its length and improving the 
head carrier movement to minimize the variation in linear 
displacement for each step of the stepper motor. This is 
essential if the track-to-track spacing is to be constant across 
the width of the tape. 

After much evaluation of various leadscrews and modifi- 
cations to the head carrier system, a head positioning sys- 
tem was developed that exhibits minimal errors that are 
highly predictable and repeatable across all mechanisms. 
Fig. 8 shows a typical final positioning accuracy plot. 
Cartridge Tracking Specifications. The greatest single im- 
provement of the HP 92245L/S cartridge over the HP 9144A 
cartridge is the replacement of a simple pin at the front of 
the cartridge with a guide roller. This part supports the 
tape on one side of the read/write head. This has allowed 
the cartridge to be respecified by the manufacturer so that 
the maximum vertical tape movement (tracking) is cut in 
half. 

Clearly, vertical tape movement results in the tape head 
being slightly off the data track to be read. The improved 
cartridge specification is essential to be able to put 32 tracks 
on the tape and repeatably recover the data. Testing both 
at the cartridge manufacturer's laboratories and at HP 
showed that the new cartridge performs well within the 
new specification, as shown in Fig. 9. 
Cartridge Media Defect Specifications. The HP 9145A 
drive is far more prone to data errors arising from media 
defects because of its narrow track size. Any drive can 
recover a read data signal until it goes below a certain 
threshold voltage that is set as a fraction of the peak read 
signal amplitude (typically 25 to 50%). The read signal 
level is proportional to the effective read track width. This 
effective track width is reduced by the presence of any 
defect. The drive is sensitive to media defects that occupy 
such a large proportion of the track width that the read 
signal falls below the threshold voltage (Fig. 10). This 
makes the HP 9145A drive, with its smaller track width, 
susceptible to smaller defects. In addition, the number of 
defects on a given piece of media dramatically increases 
as the defect size decreases. Fig. 1 1 shows the defect charac- 
teristics for the HP 92245L/S media. 



The HP 9144A and HP 91 45 A drives have two main 
weapons with which to tackle these defects. First, all the 
HP-labeled cartridges that are supplied to customers are 
certified by the cartridge manufacturer. Certification takes 
the form of writing to the tape and then reading the signal 
back. Any errors are assumed to be because of media de- 
fects; these positions on the tape are marked and "spared 
out" so that they will not be used again. If any cartridge 
has an unusually high number of blocks spared it is re- 
jected. In the case of the HP 92245L/S cartridges supplied 
to HP, this certification is performed by the cartridge man- 
ufacturer using unmodified HP 9145A drives. This im- 
mediately removes any concern about the unknown re- 
lationship between the certifying drive and a customer 
drive in reading data from the certified cartridge. Second, 
when writing data to a cartridge, both the HP 9144A and 
the HP 9145A drives immediately read back the written 
signal to verify its integrity using their read-after-write 
capability. 2 Any errors cause the drive to mark that area 
of tape as bad and then rewrite the affected data farther 
down the tape. 

The HP 9145A drive's narrow track width makes it more 
prone to small-scale media errors than the HP 9144A. This 
is overcome by the higher-quality media in the HP 92245L/S 
cartridge, which has a lower proportion of defects at the 
HP 9145A read core dimension. To cope with the slightly 
inferior media in the HP 9144A cartridges, all HP 9144A- 
written data is read back with the write core of the HP 
9145A head. This core is larger than the HP 9145A read 
core and so is less affected by the smaller defects. This 
write core approaches the size of the HP 9144A drive read 
core and so, when coupled with the HP 9145A's track seek- 
ing capability (discussed later), results in the HP 9145A's 
being able to recover a signal from an HP 91 44 A cartridge 
at least as well as an HP 91 44 A drive can. 
Track Layout. The HP 9144A drive lays down data on tape 
in a serpentine fashion, that is, one track is written in one 
direction from one end of tape to the other, then the next 
track is written directly above in the opposite direction, 
and so on up the tape (see Fig. 12a). 

A problem with this format is that the tape has a natural 
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Fig. 8. Typical head positioning error plot for an HP 91 45 A 
Tape Drive. 
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Fig. 9. Transverse tape movement plot for an HP 92245US 
cartridge shows that vertical tape movement (tracking error) 
is well within specifications. 
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tendency to step up or down as the direction is reversed 
because of the reversal of direction of tape pull. This leads 
to an error in the relative positions of two adjacent tracks 
that is at its maximum since these tracks are in opposite 
directions. 

In the HP 9145A drive this problem was alleviated by 
writing all the tracks in the forward direction in the lower 
half of the tape, and all the tracks in the reverse direction 
in the upper half of the tape (Fig. 12b). Thus, adjacent 
tracks are generally written in the same direction and so 
do not suffer from this step error. 

There is still a problem in the center of the tape where 
tracks 30 and 1 run alongside each other in opposite direc- 
tions. This is overcome by allowing a slightly increased 
track spacing between these two tracks. This increased 
spacing does not impact the track density, since the allow- 
ance only has to be incurred once rather than 32 times. 
Track Seeking. Both the HP 9144A and the HP 9145A 
drives locate the edge of the tape when each new cartridge 
is loaded. This edge is found by moving the tape head 
down until the read signal disappears. From this edge-of- 
tape position, the drive firmware is programmed with the 
number of stepper motor steps needed to reach each track. 

This dead reckoning approach for locating any track from 
the located edge of tape has been perfectly adequate for 
the HP 9144A drive. In addition, it offers sufficient accu- 
racy in positioning the head for the HP 9145A during a 
write operation. However, during reads, the HP 91 45 A may 
be attempting to read data that has been written by another 
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Fig. 10. Effect of a media defect on the read signal, (a) The 
tent effect is where a defect on the media (effectively a lump) 
causes the media to be lifted away from the tape head surface. 
The resulting shape that the media takes (looking at a cross- 
section) as it is lifted in the middle and pulled back to the 
tape head surface looks like a wigwam, hence the name tent, 
(b) An analog display of the output of the read head with a 
defect on the media. A defect results in a reduction of the 
signal below the threshold level, causing lost read data. 



drive. It is possible for the writing drive to have written 
the data to one extreme of the allowed tolerances, and then 
the reading HP 91 45 A to have positioned its read head to 
the opposite extreme. With the narrower data tracks used 
by the HP 9145A, this can lead to such poor alignment of 
the head over the written track that read data errors occur. 

The HP 9145A overcomes this track misregistration by 
a technique known as track seeking. Initially, the track is 
located in the normal way as described above. If read errors 
occur, the drive attempts to find the track by stepping the 
head alternately above the nominal position and then 
below the nominal. The step size is progressively increased 
until the errors disappear. This new position is then con- 
sidered to be the correct position for subsequent reads of 
the cartridge. 

Core Alignment. To ensure that both the read and write 
cores of the appropriate channel in the tape head are always 
centered on the data track, the horizontal alignment be- 
tween the write core and the read core must be held very 
tightly (Fig. 7). Although the write core is made slightly 
larger than the read core to minimize this problem, a limit 
is imposed by the need to fit 32 tracks across the tape. A 
tolerance analysis of the existing HP 9144A head manufac- 
turing process showed that the write-to-read core alignment 
was already at the extremes of the process capability. For 
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Fig. 11. Defect density characteristics for the HP 92245US 
cartridge. Defect density is the number of defects per square 
inch of readback area. The readback area is calculated from 
thereadtrack width, the tape length, and the number of tracks. 
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Fig. 12. Track layouts, (a) HP 9144 A. (b) HP 91 45 A. 



the HP 9145A, the tolerances had to be halved, necessitat- 
ing a radical approach to the manufacturing process. 

Several lengthy meetings with the head vendor resulted 
in an agreement to adopt a new manufacturing process that 
an exhaustive tolerance analysis showed should achieve 
the yields required. Subsequent manufacturing runs indi- 
cate that the original analyses were very accurate. 
Tape Head Mounting. As previously mentioned, the tape 
head uses a read core that immediately follows a write core 
to provide read-after-write capability. To minimize pickup 
of the write signal through direct flux linkage into the read 
core it is desirable to maximize the separation between the 
read and write cores. This separation will cause the read 
core to be offset from the written track if the head is not 
mounted perfectly perpendicular to the tape motion (zero 
azimuth angle, see Fig. 13). This problem is twice as acute 
in the HP 91 45 A mechanism because its written track is 
half as wide as that of the HP 9144A drive. 

In the manufacturing process for the HP 9 144 A the 
azimuth angle of the tape head is set by running a tape 
past the head and measuring the relative times at which 
the four cores see patterns prerecorded on the tape. While 
this process provides a good method for measuring the 
required accuracy, it takes a fairly long time to perform for 
each head and the adjustment of the head position to 
achieve zero azimuth is extremely difficult. 

A design change to the head greatly simplifies this re- 
quirement while also speeding the head mounting process. 
The central section of the head was increased in size so 
that it protrudes above and below the outer sections. Since 
the interfaces between these sections define the core gaps 
and hence the effective positions of the read and write 
cores, a tool was designed that references off the exposed 
sides of the central head section to set the azimuth angle 
of the head accurately. This design change to the head also 
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Fig. 13. Azimuth angle. For clarity, only one of the two pairs 
of cores is shown. 

allows a simple mechanical means of verifying the accuracy 
of the azimuth angle of the mounted head. 

Conclusion 

The HP 9145 A drive is now shipping to customers. Strict 
quality control measures are being used throughout the 
manufacturing process and further stressed-environment 
audit testing is being applied to the drives produced. So 
far these tests have verified the ability of the HP 9145A 
drive to achieve its original performance and reliability 
goals. 
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Reliability Assessment of a Quarter-Inch 
Cartridge Tape Drive 

Aggressive quality standards were verified by over 97 ,000 
test hours before manufacturing release and are audited 
continually in production. 



by David Gills 



THE QUALITY GOALS FOR THE HP 9145A Tape 
Drive included a failure rate that was half that of 
the earlier HP 9144A, an error rate performance that 
was 10 times better than the HP 9144A's, the same useful 
life as the HP 9144A, and full backwards compatibility 
with all HP '/4-inch data cartridges. 

The reliability test plan showed that to be able to halve 
the failure rate value within the development time of just 
over 1.5 years, then approximately 100 prototype units 
would be needed, resulting in an accumulation of 97,000 
test hours before manufacturing release. Reliability growth 
was monitored using the Duane plot technique, 1 and there 
were interim goals at each of several checkpoints within 
the development program. 

The reliability of this product is also being continuously 
assessed during manufacturing. For this purpose a detailed 
manufacturing reliability audit test schedule was de- 
veloped. This will be discussed in more detail later in this 
article. 

Tape Head 

As described in the article on page 67, the tape head had 
to be totally redesigned because of the reduction in the 
track width and the increase in the tape speed. The effect 
of the tape head on the track placement accuracy is gov- 
erned mostly by the mechanical tolerances of the core sizes 
and the positioning of the cores on the head. Shock, vibra- 
tion, and temperature can lead to inaccuracies in the track 
placement. A full test program was carried out to explore 
and quantify all these effects on the performance of the 
drive. 

The temperature margin above the storage specifications 
of the HP 9144A tape head before damage is incurred is 
well-understood from past test data. The elements of the 
manufacturing process that affect this margin are also well- 
understood. 

The first mode of failure of the HP 9144A tape head 
when the temperature is increased outside the nonoperat- 
ing temperature limits is a deformation of the profile of 
the head. This is caused by stress relieving of the plates 
that make up the structure of the head. It is a permanent 
failure, making the head unsuitable for further service. The 
manufacturing process has been radically changed to elimi- 
nate this mode of failure, which is now well-understood. 
By eliminating this mode of failure in the design of the 
new head, a much wider reliability margin has been 
achieved, making the head less sensitive to manufacturing 



variations. This was clearly demonstrated during the test- 
ing. No permanent damage was seen on any of the data 
heads following extensive strife (stress + life) testing. 

Head Wear 

Wear of the head is accommodated until the depth of 
the wear reaches the throat depth of the core. When this 
occurs, the head performance drops off dramatically and 
without warning. 

Since the speed of the tape over the head has doubled 
from the existing HP 9 144 A, head wear characteristics have 
become an issue. As the tape speed increases, the frictional 
forces on the interface increase. However, aerodynamic 
compression of the air behind the tape at these higher 
speeds can have the opposite effect on the wear rate. This 
phenomenon is very difficult to describe theoretically, so 
the relationship had to be confirmed by a controlled exper- 
iment. 

Testing showed that the rate of wear of the head took on 
the standard exponential shape when plotted as a function 
of time, as shown in Fig. 1. The measurements were taken 
using a Rank Taylor Hobson Talysurf 10 machine. A typical 
profile is shown in Fig. 2. 

The throat depth of the core is nominally 40 /xm, so it 
can be seen from Fig. 1 that there is considerable margin, 
even based on the small sample of drives tested. Therefore, 
head wear is unlikely to be the first mode of wearout failure. 
This was confirmed during testing. The capstan motor was 
found to be the first mode of wearout failure in the product. 
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Fig. 1. Head wear as a function of test hours for production 
HP 91 45 A heads. 
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This will be discussed later in more detail. 

Positioning Tolerance 

Because of the increase in the requirement for track place- 
ment accuracy, the tolerances on the design and manufac- 
ture of the leadscrew that drives the head up and down 
across the tape had to be tightened significantly. 

The leadscrew design for the HP 9145A is the same as 
for the HP 9144A. However, because of the precision re- 
quired, the manufacturing tolerances were tightened signif- 
icantly. On the HP 9144A, the thread pitch dimension has 
a ±5-/Lim tolerance, which is accumulated along the length 
of the thread. This will obviously give a large overall toler- 
ance on the length of the leadscrew. On the HP 9145A, the 
thread pitch dimension also has a ±5-/xm tolerance, except 
that it is not accumulated along the length of the leadscrew. 
This gives an overall tolerance for the length of the 
leadscrew of ±5 /xm. 

The manufacturing processes that influence this preci- 
sion have to be controlled using statistical process control 
techniques to maintain the required accuracy. The data 
from the control charts is continually being monitored. 



Repeatability of the track placement was critical to the 
success of the project, so a rigorous test program was 
adopted to assess its impact on the reliability of the drive. 
The leadscrew is machined and ground precisely from non- 
magnetic stainless steel, but the nut that runs along it is 
made out of acetyl. The two main problems that arise are 
the accuracy of the leadscrew and the long-term accuracy 
of the nut. Since the nut is made of a much softer material 
than the leadscrew, we needed to ensure that there was no 
significant wear or load deformation. A key factor in the 
design of the head positioning system is that the head car- 
rier is preloaded with a spring. This ensures that there is 
no mechanical hysteresis or backlash in the system, thereby 
driving the nut on one face of the thread only. 

Shock and vibration testing was carried out to check for 
these issues, and it was found that this design has a very 
wide margin of safety over the quoted operating specifica- 
tions before track placement becomes an issue. 

Capstan Motor 

Since the tape speed of the HP 9145A is twice that of 
the HP 9144A, that is, 120 ips compared with 60 ips, the 
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capstan motor is required to run faster and have a higher 
torque. This allows the tape mechanism to start and stop 
more rapidly and accelerate to normal operating tape speed 
more quickly. These factors affect the overall life of the 
product, and since the goal for the useful life of the HP 
9145A is the same as that of the HP 9144A, we needed to 
assess these parameters. 

Working closely with our vendor, we were able to feed 
back test data from the development work being carried 
out in the laboratory from failures that were uncovered. 
The increase in speed and start-up torque showed that the 
current density at the brushes of the motor was too high, 
resulting in an unacceptable rate of brush wear. It was also 
found that the debris from the brushes was finding its way 
into the motor bearings, pointing to a need for shielded 
bearings. 

The vendor was able to change the brush shape and 
material to extend the life to meet the goals. This was 
subsequently verified by extensive testing by the motor 
manufacturer and HP. 

Printed Circuit Assemblies 

Both the servo control printed circuit assembly and the 
main controller printed circuit assembly are newly de- 
signed boards, and as such had to be tested by a rigorous 
performance and stress test program. Again, working 
closely with our vendors, we were able to attack potential 
failure modes before the design was put into full produc- 
tion. An example of a typical component failure that was 
uncovered and eliminated is a crystal oscillator that failed 
during strife testing. Subsequent analysis showed that the 
failure had been caused by thermomechanical expansion 
of the terminals that support the crystal plate within the 
device. The movement of the terminals had resulted in a 
fracturing of the brittle crystal plate, rendering the compo- 
nent unserviceable. Since the vendor was unable to help 
in this instance, the component was second-sourced, re- 
sulting in much better quality. 

Cartridge 

The design of the HP 9145A relies very heavily on the 
quality of the media that it uses. With the performance of 
the drive increased so dramatically, the existing tape was 
inadequate. Although the older tape is compatible with the 
HP 9145A, its longer-term reliability was questionable. A 
reduction in defect size was critical to the reliability goals 
that were set for data integrity. The media defect size be- 
comes far more critical as the width of the track decreases. 

The project was discussed with the vendor that supplies 
the media, and jointly we agreed that a new tape needed 
to be introduced. This was a very extensive development 
program, carried out by the media manufacturer in parallel 
with the development of the drive at HP. Some of the prob- 
lems associated with this development work have already 
been outlined in the article on page 67. 

The cartridge mechanics were also redesigned to give 
better tape handling characteristics, resulting in better tape 
tension and drive force control. 

The hubs that support the tape were redesigned from a 
new material, so that the cartridge is able to cope with the 
additional tape speed without wearing the hubs at an un- 



acceptable rate. 

The drive belt that runs on the tape (wound around the 
hubs), was also redesigned from a new material, and is 
being manufactured with a new process, giving more stable 
belt tension. 

An additional tape guide was designed in to provide 
better tape placement accuracy. Since the tracks on the HP 
9145A are half the width of the tracks on the HP 9144A, 
this was a critical area in the design of the cartridge. 

The guide rollers were also redesigned, since the increase 
in tape speed caused the rollers to become a source of 
unacceptable acoustic noise. Resonances were built up 
from out-of-balance forces of the rollers running at high 
speed, and were transmitted through the case and baseplate 
of the cartridge. 

Backwards Compatibility 

Since the HP 9145A is intended as a natural upgrade 
path from the HP 9144A, it must be able to read existing 
tapes that have been written by the HP 9144A and other 
HP Winch tape drives. Complexity is added by the variety 
of revisions of each product and of the Winch cartridge. 
The HP 9145A has to be compatible with the entire '/4-inch 
tape product family over the operating temperature range, 
for any data pattern written by any other compatible drive. 
To prove the error rate performance over all possible com- 
binations, the testing required would take over five years! 

Some of the variables to be considered when concerned 
with interchange and backwards compatibility are temper- 
ature, humidity, data pattern, length of tape, data source, 
tape age, tape type, revision of unit, altitude, shock and 
vibration, 120V/240V, and age of drive. Using Graeco-Latin 
square (statistical design of experiments) techniques, 2 we 
were able to get this test program down from 260 combina- 
tions to a program of 16 representative combinations. 

On each of the 16 runs, 10 11 bits of data was handled by 
each drive (the error rate specification is 1 bit in error for 
10 11 bits of data handled). The tests were designed to find 
combinations that did not work at all or any trend or pattern 
that could indicate a combination that would potentially 
not meet specification. 

The program was very extensive, and the testing was not 
able to find a combination that indicated that the specifica- 
tions could not be met. The HP 9145A showed that it was 
able to read data from any combination that it was tested 
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Fig. 3. Typical distribution of faults in burn-in testing. 
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against. 

Test Program 

At the completion of the test program, 97 prototype units 
had been tested, accumulating over 97,000 test hours. Over 
500 tapes were used during the performance and inter- 
change testing, and a total of over 150 failures were found. 
These failures can be broken down as follows: 

Mechanism related failures: 70% 
Controller related failures: 20% 
Firmware related failures: 10% 

Audit Testing 

Although the tests described so far confirmed the relia- 
bility of a sample of prototype and early production drives, 
they in no way reflect the factors that will affect the relia- 
bility of the product in the long term, that is, factors related 
to the manufacturing process. Although the HP 9145A has 
been highly leveraged from the HP 9144A, with many im- 
provements to the product and the process based on the 
wealth of information available, the reliability of the prod- 
uct in the long term cannot be measured or quantified 
unless real data is at hand. The warranty system, which 
records the numbers of failures in the field, provides data 
that is obviously too late. What is needed is a means of 
controlling the reliability of the drives with a closed-loop 
system that has a response that is almost immediate. The 
only way to do this is by continued unit testing on an audit 
basis. 

An audit test strategy was devised for the HP 9145A that 
will enable manufacturing engineering to keep a tight con- 
trol on process variations that affect the reliability of the 
product. A secondary objective of the audit testing is to 
ensure that the data being collected correlates closely with 
the data that is being continually collected from the war- 
ranty claims. 

Much data is available from the prototype testing, and 
this was used as a basis for determining the general content 
and duration of each audit test. Also, a comparison was 
made with other divisions of Hewlett-Packard to appreciate 
some of the problems encountered in such testing. 

The audit testing has three phases: burn-in, customer 
environment, and life tests. 

Burn-In. This is performed on 100% of all units manufac- 
tured, and lasts for approximately 14 hours. This test is 
solely designed to catch the dead-on-arrival or infant mor- 
tality failures that somehow escape the manufacturing final 
test. Although the final test is considered to be adequately 
thorough in testing the total functionality of the unit, there 
are often intermittent faults or failures caused by weak 
materials that survive the final test. These intermittent 
faults often appear very early in the product's service life. 

The format of the burn-in test is based on data from the 
prototype testing. It consists of ten cycles of power cycling 
and self-tests, loading tapes, performing read/write and 
read-only error rate tests, performing locate and read and/or 
write operations, comparing data with the host system, and 
unloading and unlocking the cartridge. 

The results from the initial nine months of testing show 
that the faults are being uncovered very early in the test 



cycles (see Fig. 3). This obviously means that there is a 
real opportunity for shortening this test after more confi- 
dence is built up from a bigger test history. 
Customer Environment. These tests are designed to simu- 
late more closely the environment seen by the product 
during the warranty period. Hence, the failures found are 
intended to mirror the failures found in the warranty sys- 
tem. The duration of this test has been established from 
an assumed typical use of the product. The test is not 
performed on all units, but on a sample of approximately 
5% of production. The testing simulates the time from when 
the unit leaves the end of the production line to the end 
of the warranty period. Therefore, the shipping of the prod- 
uct, the end-use handling, and the in-service operation of 
the product are simulated. The details of the customer en- 
vironment are as follows: 

■ Book out unit from finished goods. 

111 Drop unit in packaging onto concrete from a height of 
1.2 m. 

B Make visual and functional inspection for cosmetic dam- 
age, accessories completeness, failure to power-up and 
pass self-test. 

a Thermal cycle between the operating limits of the drive 
for 40 hours. 

81 Apply nonoperating vibration at 1.5 times specification 
for one hour. 

■ Compare data at ambient temperature between host and 
drive for 100 hours. 

■ Interchange data between drives in product family for 
24 hours. 

The test cycle lasts for one week, after which the units 
are returned to the production line for shipment. These 
units are considered to be some of the most reliable to leave 
the factory, since they have had all the infant mortality 
problems removed, and have proved to work reliably for 
a significant period of time. 

Life. The life testing of the HP 9145A is currently being 
carried out by the suppliers of the media. This is because 
the media suppliers own many HP 9145As and use them 
at a very high duty cycle to certify all the tapes that are 
manufactured by them. This enables HP to use this infor- 
mation without cost. Obviously we need to be working 
very closely with these suppliers to ensure that the infor- 
mation that they supply to us is accurate and complete. 
The collection of this data will continue into the foreseeable 
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Fig. 4. Distribution of faults among the various subtests of 
the burn-in test. 
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future since the data is obtained free and will be needed 
to ensure that any changes in the manufacturing process 
do not affect the long-term reliability of the drives. 

Results of Audit Testing 

The first nine months of data has shown some interesting 
results. Problems are being uncovered in the burn-in test, 
as expected. This justifies its presence and quantifies the 
costs saved from warranty claims arising from very early 
failures, not to mention the hidden costs of customer dis- 
satisfaction. 

It can be seen from Fig. 3 that the majority of failures 
that have been uncovered so far have occurred very early 
in the test program. After the fourth cycle, which is 1.3 
hours after the start of the test, most of the problems seem 
to have been found. This data indicates that a reduction 
in the test time will find the same level of faults, but will 
save substantial cost in manufacturing overhead (the cost 
of the tapes is probably the biggest factor here). 

Fig. 4 shows the tests that are most effective in producing 
the faults. This data agrees with the test data from the 
earlier prototype testing, and is useful feedback for reliabil- 
ity planning on future projects. 

The customer environment testing is currently showing 
a very similar trend in the results. One year after introduc- 
tion over 8,000 units have been shipped to customers. The 
warranty data shows that the actual failure rate of the HP 
9145A is better than the failure rate goal at introduction. 
As a result of the audit testing strategy, the warranty failure 



rate continues to fall to a point where today the warranty 
failure rate is half of that measured a year ago. 
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Use of Structured Methods for 
Real-Time Peripheral Firmware 



HP's Computer Peripherals Bristol Division made some 
significant changes in their firmware development process 
to ensure that they met a demanding development schedule 
and still produced a quality product. 

by Paul F. Bartlett, Paul F. Robinson, Tracey A. Hains, and Mark J. Simms 



PRODUCTIVITY AND CONCERNS about quality may 
seem to be opposing concepts when product develop- 
ment time is short. However, with planning, the 
proper tools and a good development method, productivity 
and quality objectives can be achieved and still meet the 
time-to-market goals. In the development of the HP 9145A 
Cartridge Tape Drive at HP Computer Peripherals Bristol 
Division (CPB) the firmware was always on the critical 
path during the entire product development time. We had 
to produce reliable prototypes of the HP 9145A for testing 
with the target machines one year after the project start 
date. We realized at the beginning of the project that if we 
used the firmware development process we had at the time, 
we could not meet the schedule and still produce a quality 
product. Some of the problems we had in our development 
process at the time included: 

■ Total reliance on text for firmware specifications. There 
were very few graphical representations for the system 
architecture, data, and module organizations. 

■ Firmware testing was different for each project and the 
effectiveness of testing was not measured. Also, there 
was no overall test planning process. 

■ Except for the number of noncomment source statements 
(NCCS), no metrics were collected. 

■ Tool support consisted of emulation, source code con- 
trol, and editing on HP 64000 Logic Development Sys- 
tems. There were some tools for text documentation and 
structured design which existed on a variety of systems. 
Improvements were made to our development process 

in the areas of planning, methods (analysis, design, and 
testing), and metrics (process measurement). The most sig- 
nificant changes involved the use of structured analysis, 
structured design, and structured testing. Structured design 
had been used on past projects for module design and the 
technique had worked well. 

Each engineer on the project was equipped with an HP 
9000 Series 300 workstation which was used for program 
development and emulation. A network of workstations 
was created with one workstation dedicated as a central data 
base for configuration management (i.e., keeping track of 
all versions of our documentation and code). To enable us 
to use the structured analysis and structured design (SA/SD) 
methods effectively, HP Teamwork/SA was installed on 
each workstation. This product allowed us to produce all 
of the real-time structured analysis and structured design 



documentation for the HP 9145A firmware, and assisted 
in ensuring analysis and design consistency between the 
members of the team. Other software tools that we used 
included a code-efficient cross compiler from C to 68000 
assembly language and a 68000 emulator. 

This paper describes our experiences with applying SA/SD 
techniques and tools to the development of the HP 9145A 
firmware. 

Real-time Structured Analysis 

Structured analysis is a method that enables designers 
to partition a system into manageable component process- 
es. It helps to identify the system requirements and func- 
tionality so that consideration about implementation de- 
tails, such as system architecture and module design, is 
delayed until necessary. This allows the designer to keep 
as many design options open as possible. Structured 
analysis 1 has been successfully applied to business and 
commercial systems where the emphasis is primarily on 
data flows and processes. In real-time systems, in addition 
to data flows and processes, control and timing are also 
major considerations. For the HP 9145A firmware develop- 
ment we used some parts of the structured analysis real- 
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Fig. 1. Modelling control flows and data flows in real-time 
structured analysis. The function of a process is to perform 
the operation implied by its name. The vertical bar represents 
the interface to a state machine. 
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time extensions described in references 2 and 3. 

Real-time systems have two features that nonreal-time 
structured analysis cannot model. One is the ability to dis- 
tinguish between the flow of control signals such as inter- 
rupts, and simple data flow such as flags or values. In 
real-time structured analysis, information flow between 
processes is represented by control flows for control signals 
and events and data flows for plain data (see Fig. 1). The 
control flows shown in Fig. 1 send a signal to activate or 
deactivate a process. For example, when a user presses the 
Unload button on the front panel, the state machine sends 
the TapeUnloadCommand signal to activate the process Pre- 
pareToUnload. The data flows represent information a pro- 
cess must retrieve from elsewhere in the system (e.g., a 
data store or another process) to perform its operation. For 
example, in Fig. 1 the process PrepareToUnload retrieves data 
about the CartridgeStatus from the Status data store. 

The other deficiency of ordinary structured analysis is 
in modeling sequences of real-time operations. These are 
situations where timing or the order of responding to events 
and actions is very important. Starting a servo motor and 
waiting until it is up to speed before proceeding, or enabling 
DMA transfer of data to tape, are examples where timing 
and sequence are critical. One method used in real-time 
structured analysis to model sequence control is the state 
transition diagram (STD). State transition diagrams are 
used to model state machine behavior and to show how 
different system states are influenced by control signals. 
Fig. 2 shows the state transition diagram for the model 
shown in Fig. 1. This state machine is designed to respond 
to events such as Unload button pressed. Self Test button 
pressed, cartridge inserted, and so on, and still read com- 
mands from the HP-IB. 

Real-time structured analysis can be used to help parti- 
tion the hardware and software functionality for a whole 
system. In our situation the division between the hardware 
and firmware functions had already been decided before 
we began using the method. Therefore, we concentrated 
on using the methods only on the firmware. 

Context and Data Flow Diagrams 

Our first task was to define a context diagram for the HP 
9145A firmware. A context diagram enables the designer 
to identify all the external entities such as other systems, 
users, and peripherals, with which a system must com- 
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Fig. 2. A portion of the state transition diagram for the model 
shown in Fig. 1 . The number in each block is a state identifier. 
There are at least 18 states in this state machine, but for 
clarity, only four essential ones are shown. 



municate. The context diagram for the HP 9145A firmware 
is shown in Fig. 3. There are three components to a context 
diagram: terminators, data and control flows, and a single 
process. Terminators represent external entities that can 
be either sources or sinks depending on whether they trans- 
mit or receive data. The data and control flows represent 
the communication paths between the terminators and the 
single process. The single process defines the central role 
of the system being designed. In our case the firmware is 
used to control and monitor the HP 9145A tape drive. 

From the context diagram we developed a top-level data 
flow diagram (DFD) which defines the main firmware tasks 
and the interfaces between them (see Fig. 4). The interfaces 
between the tasks consist of messages passed via an inter- 
process communication module in the operating system. 
The effort involved in developing the data flow diagram 
enabled us to understand how to divide the system into 
manageable pieces for development and further analysis. 
Our development plan was refined so that the analysis 
phase was divided into smaller stages in which functions 
within each task could be analyzed. This enabled us to 
plan reviews to occur whenever one of these stages was 
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Fig. 4. Data flow diagram for the 
HP 91 45 A firmware. 



completed. We could review a small amount of documen- 
tation every two or three weeks, instead of waiting for 
months to review a vast amount of information. 

The tasks shown in Fig. 4 perform the following func- 
tions: 

0 Channel Task. The channel task controls the interface 
between the operator, the host computer system, and the 
HP 9145A firmware, 
a Buffer Task. The buffer task controls the flow of data 
between the HP-IB interface, an internal data buffer, and 
the magnetic medium (tape). 
>2 Device Task. The device task controls the read/write cir- 
cuitry and the tape mechanism. 
■ Utility Task. The utility task contains functions used to 
perform switch and button debouncing and control the 
operation of the lights on the front panel of the drive. 
The data and control flows in Fig. 4 represent the inter- 
process communication between the tasks. Interprocess 
communication in the HP 9145A firmware is implemented 
by a number of mailboxes used for holding messages or 
commands. 

Each of the tasks has its own context diagram and its 
own set of external entities. Fig. 5 shows the context dia- 
gram for the device task. From these context diagrams de- 
tailed DFDs were generated for each task. Fig. 6 shows a 
portion of the DFD for the device task and Fig. 7 shows a 
portion of the DFD for the process Read/Write Operations which 
appears in Fig. 6. When the DFDs were leveled to primitive 
processes (processes that cannot be decomposed any 
further) process specifications were created like the one 



shown in Fig. 8 for the process ExecSingleShotRead which 
appears in Fig. 7. The number and complexity of the data 
and control flows increased as the design became more 
detailed. For example, the data flow diagram in Fig. 6 ac- 
tually contains 24 control flows and 46 data flows between 
the processes. HP Teamwork/SA was used to create and 
maintain a central data dictionary data base for the whole 
firmware system. A data dictionary is a method for defining 
every data flow, control flow, and data store used in a 
system. The central data base allowed us to maintain data 
consistency between the various tasks. Because we were 
putting a great deal of effort into analysis, the data dic- 
tionaries became colossal. HP Teamwork/SA was really 
helpful here because it provides a checking facility that 
makes sure the data and control flows are consistent be- 
tween levels of the system model. We ran the checking 
facility before each review so that the reviewers could con- 
centrate on checking for correct functionality instead of 
spelling and consistency errors. Fig. 9 shows some of the 
data dictionary entries for the context diagram shown in 
Fig. 5. 

A large proportion of the analysis of the firmware for the 
project involved the analysis of control. State transition 
diagrams served as a major part of this analysis. These 
diagrams allowed us to concentrate our control structures 
in a small number of places. To ensure manageability and 
readability most of our STDs consist of less than 20 states. 
An STD with more than 20 states becomes very confusing 
and hard to read. A portion of of an STD for the process 
ExecSingleShotRead from Fig. 7 is shown in Fig. 10. 
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Lessons Learned 

Five months had been allocated for the structured 
analysis portion of the firmware development and we man- 
aged to finish on time with two weeks to spare. Had we 
been more experienced with the methods and tools we 
would have finished sooner. Some of the observations and 
lessons we learned from using real-time structured analysis 
include: 

■ A lot of effort, maybe too much, was expended at the 
very top level of each task. One reason for this is that 
we had to do some informal lower level analysis to de- 
cide whether the top level solution produced was good 
enough. Having spent this effort early we found that 
when it came time to do formal lower level analysis the 
task was much easier. 

■ In some areas of the analysis we found that it was very 
difficult to produce a solution because of the amount of 
fan-in* to most processes associated with hardware de- 
pendent areas. We encountered some difficulty with 
using structured analysis for analyzing functionality as- 
sociated with time-critical control of hardware. There 
are some techniques in the SA/SD real-time extensions 3 
that can be used to analyze critical hardware/software 
timing situations. However, we did not get a chance to 
use these methods. In addition, we were trying to specify 
detailed algorithms using data flow diagrams, which is 

"Fan-in is delined as a large number of processes all making calls lo one common process. 



not the intention of the method. 

■ Too much effort was expended considering the im- 
plementation aspects of the system instead of defining 
the system functionality. This resulted in process specifi- 
cations that tended to be trivial and not very useful. 

■ By the end of the structured analysis phase all of the 
engineers on the team thoroughly understood what their 
portion of the firmware was expected to do as well as 
what some of the rest of the firmware was doing. 

■ Because of the thorough analysis that had taken place a 
large number of anomalies were discovered and fixed in 
the original project specifications (external reference 
specifications). 

■ After structured analysis there were very few changes 
to the functionality of the product, except in areas where 
the characteristics of the mechanism or the tape were 
not fully understood. 

Structured Design 

In this phase of the development the data flow diagrams 
developed during the structured analysis phase were used 
to design the architecture and hierarchy of functions for 
the HP 9145A firmware. In most cases this process resulted 
in structure charts like the one shown in Fig. 11 for the 
process ExecSingleShotRead. In one task we found that there 
was no need to develop structure charts because the struc- 
tured analysis produced such a flat structure, all based on 
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ule specifications were written for all the procedures. These 
module specifications were written so that they could be 
used as procedure headers for the code. Fig. 12 shows the 
module specification for the state machine SSReadlnitialize 
shown in Fig. 10. In many instances part of the module 
specification was extracted directly from the process 
specifications written during the structured analysis phase. 
At this point of the project module specifications became 
the most important documentation. All changes that were 
made to the code were documented in the module specifi- 
cation for the affected function. Keeping the structured 
analysis documentation up to date was relatively tedious 
and time-consuming. However, towards the end of the test- 
ing phase this documentation was updated to match the 
final design of the firmware. This showed that even with 
an automated tool to enter a design, there must be a mech- 
anism to update the design documentation automatically 
when changes are made during implementation. 

Structured Testing 

Structured testing encompasses the planning, design, 
documentation, and execution of tests. It is a method for 
managing the overall testing process and for providing 
traceability between the various types of test documenta- 



calls from a state machine, that we felt that the exercise 
would not yield any useful extra information. 

The production of structure charts was limited only by 
the speed with which information could be put into HP 
Teamwork/SA. This was because there was so much detail 
from the structured analysis phase that the design came 
together with very little effort. Also, as in the structured 
analysis phase, the data dictionary proved to be invaluable 
and the HP Teamwork/SA checking facility helped to en- 
sure that consistent designs were produced. 

In parallel with producing structure charts, detailed mod- 
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I nput /Output : 



Tr lggorSlngloShotRoad 
SSOpcrat ionComplete 
Devi coCommandQueue 
SingleShotCommand 
Singl oShot Report 
GlobalStatusInf ormat ion 
GoodBlocksRequl red 
ReadWritelnfo 

Body: 



cont rol_out 

control_ln 

data_inout 

data_in 

data_out 

data_inout 

data_out 

datal nout 



•control flow out" 
•control flow in* 
•bidirectional data flow- 
■data flow in* 
•data flow out" 



Translate parameters into the appropriate command queue settings 
and other stored information. 

Trigger the tingle shot read state machine. 

Walt for completion. 

Compile status return value derived from Comfail and abort 
condi t ions . 

Reset Comfail and any other abort conditions generated during the 
test . 

Got more status from ReadWritelnfo ( Ma intonanceTrackOvor f low and 
TapeNotWrittenTo ) . 

Gather status. 

Return result . 

Fig. 8. The process specification for the process Exec- 
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Clock (data flow, eel) = 

■A continuous data flow indicating the number of ticks of the 
clock. • . 

ResetClock (control flow) = 

- Control from device tells the operating system - 

• to zero the millisecond timer. « 

DDCCommandorStatusororBusy (data flow) » 

[ DDCCommand ; BusyStatusBi t ; DDCReport | ReportStatusBlt 1 

DeviceCommand (data flow) = 

• The DeviceCommand splits into six groups of commands. 

• Each command in each group contains an opcode identifying ■ 

• the type of command, a subcode identifying the command 

■ itself and a number (sometimes 0) of parameters. • 
[ DiagnosticCommand | TapoLoadCommand ! ReadBl ockCommand i 

ResetDeviceCommand : TapeUnloadCommand ; Ut i 1 ltyCommand ! 

Wr iteBlockCommand ] 

DeviceReport ( data flow ) = 

•Report contains 10 16 -bit words where the order of the words 
•is significant. There is a seperate report for each class of 
•command. 

[ DlagnosticReport | TapeLoadReport | ReadWr i teReport ! 
ResetReport : TapeUnloadReport ; Ut i 1 1 tyReport ] 

IPCDeviceFlags (data flow, del) » 

- Flag value • True or False. 

Threshhold (data flow, pel) • 
-Hardware - 

-8-bit numeric valus to adjust the effective gain of the read 1 
-amplifier. . 

OverThresholdReset (control flow, del) = 
•Hardware • 

•Control to reset the overthreshold latch " 

ServoCommand (data flow) ■ 

[NormalOperat ionCommand ; SpecialFunct lonCommand ; 
SorvoTransparentCommand ! Ut 1 1 i tyDi agnost lcCommand ] 

Data Dictionary Notation 

eel ; Continuous element. An attribute that indicates that the 
item can take on a large number of values. 

del : Discrete element. An attribute that indicates that the its- 
can take on a finite number of values. 



pel : Primitive element. An item that cannot take 
values or be be further decomposed. 

: Is -Equivalent -To . 

[!] : Either-Or selection. 

♦ : And (sequence selection). 

• • : Comments. 



any other 



Fig. 9. A portion of the data dictionary definitions for the data 
and control flows for the process ExecSingieShotRead. 
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Fig. 10. -A portion of the state transition diagram for Exec- 
SingleShotRead 

tion. Structured testing tends to minimize the cost of prod- 
uct development by finding problems as early as possible 
before the cost of rework is high. An example of this might 
be when a test designer is writing a test and discovers that 



a specification is incomplete or ambiguous. If the specifi- 
cation defect is removed before coding takes place the cost 
of defect removal is low. 

Our test strategy was based on traditional structural and 
functional test techniques 4 and well-coordinated test plan- 
ning. 5 A hierarchy of test plans (Fig. 13) was produced for 
the whole product. Each sector of the system, mechanical, 
electronics, and firmware, had a similar hierarchy of test 
plans. These test plans were produced from the top down 
so that the overall firmware test plan was produced before 
the test plans of any individual tasks. Once the code had 
been written, the tests described in the test plans were 
executed starting from the bottom. By writing the test plans 
in parallel with designing the firmware we found a lot of 
problems that otherwise might have been overlooked. 

To minimize the effort required during the testing phase 
an automatic test package was developed to run most of 
the tests. This test package accepted test scripts, exercised 
the product, checked for correct responses, and reported 
any anomalies to the test engineer. This enabled us to run 
tests during periods when there were no engineers available 
to monitor the tests. 

All problems were recorded in a defect tracking system. 
This system was used to monitor the number of defects 
found, their severity, and the reason for each defect. It was 
also used to monitor the current status of each defect so 
that we could determine how many defects still had to be 
resolved. From this information we were able to monitor 
the progress of the project, and to tell whether the defect 
rate was under control. 
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Fig. 11. A portion of the structure chart for ExecSingle ShotRead. 
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Results 

As mentioned earlier, the firmware for this project was 
on the critical path from the beginning. As it turned out, 
our progress was so good that we were able to meet all 
major deadlines. Table I shows that our original estimates 
were very accurate and we achieved very respectable fig- 
ures for our estimation quality factors (EQFs)* for each 
phase of the project. 



Table I 

Project Estimation Quality Factors (EQFs) 



Activity 


EQF 


Estimated 


Actual 


Estimated 


Actual 






Elapsed 


Elapsed 


Engineer 


Engineer 






Months 


Months 


Months 


Months 


Analysis 


9.0 


4.5 


5.0 


20.0 


22.5 


Design 


7.5 


1.7 


2.0 


6.5 


7.5 


Coding 


9.3 


1.1 


1.25 


6.25 


7.0 


Functional 


11.5 


4.2 


4.6 


21.0 


23.0 


Testing 












System 


5.0 


4.0 


5.0 


12.0 


15.0 


Integration 












Total Project 


8.1 


15.5 


17.85 


65.75 


75.0 



During the analysis phase we defined over 420 processes 
on the data flow diagrams which resulted in about 570 
procedures in the final product. The final code consisted 
of 24 KNCSS (thousand lines of noncomment source state- 
ments), and 123 kilobytes of object code. 

Defects were tracked and a chart maintained to show the 
cumulative number of defects detected as a function of 
elapsed time. A code path monitor, which kept a count of 
the number of code statements tested, was run while the 
regression test package was being run. When the total test 
package was run, 85% of the statements were being exer- 
cised. The code path monitor enabled us to verify that 
100% of the most critical areas of the code were being 

"EQF gives the reciprocal ol Ihe average discrepancy between the estimated and the 
actual duration of a phase An EQF of 8 is considered lo be good lor software estimates. 
See reference 6 for more information about EQF 



/ / 

/• Module Name : d_ss_read_init ial 1 se File : k_smc_lnit •/ 

/• Function : Set up the head conmand for a single shot •/ 

,/• read fron tape. Check the DDC to make sure •/ 

/• it is working. • / 

- I 

/* */ 
/• Parameters : None -/ 
>• •/ 

/ I 

/• •/ 
/• Global! : -/ 
/- •/ 
/• Global Name I/O Status Type •/ 

/ "/ 

/• •/ 
/• d_report_record write devlce_report_type -/ 

/• d_headcom write command_rr cord •/ 

/• •/ 
t / 
/• •/ 
/• Function Result: •/ 
/• */ 
/• 0 - SSReadlnitOK -/ 
/• 1 - FallcdToInltSSRoad •/ 
/* */ 

t 

/• •/ 
/• Process : •/ 
/• •/ 
/• Use d_so_lnltlalise to do most of the initialisation. •/ 
/• If this succeeds, then •/ 
/• d_headcora- 'coramand_stat us .read_f lag » TRUE •/ 

/• d_headcom- >comnand_status .wr lte_f lag « FALSE •/ 

/• Set the mode for ddc head select according to tape typo. •/ 

/• For old HC tapes, reads should use the write heads, •/ 

/• otherwise use the read heads. »/ 

/• RETURN InltlalisedOK. •/ 

/• otherwise •/ 
/• set d_roport_record.devlce_status .comfal 1 • TRUE •/ 
/« return FalledTo Initialise. •/ 
/• •/ 

/ / 

/• •/ 
/• Notes: •/ 
/• •/ 
/• •/ 

/ / 

/- •/ 
/■ Author : Kevin Jones Date : 5 June 1987 •/ 

/• •/ 
/• Modification History •/ 

/ •/ 

/• Modifier Version Date Reason -/ 
/• •/ 
/ 



Fig. 12. One of the module specifications for the state tran- 
sition diagram shown in Fig. 10. 

exercised. These figures do not take into account the extra 
code coverage that individual engineers achieved during 
their module testing activities. Our expectation at the outset 
of the project was that we would achieve 70% code cover- 
age. Fig. 14 shows the cumulative number of defects found 
and the known code coverage, and compares the actual 
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Fig. 14. Cumulative defect and code coverage. 

figures against the expected figures. This data illustrates 
the completeness of testing performed. 

Conclusion 

Structured methods really are appropriate for the de- 
velopment of firmware on major projects. The mistakes 
that we made were mainly caused by our inexperience 
with the methods and tools. Access to an experienced prac- 
titioner as a consultant or as a member of the team would 
have eliminated many of our problems. We carried out 
these firmware development process changes to meet the 
needs of a particular product development. Our challenge 
now is to continue to improve our firmware development 
process and extend what we have learned to future projects. 
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Product Development Using 
Object-Oriented Software Technology 

Object-oriented technology is rapidly becoming an 
accepted technology for designing and developing software 
systems. This paper provides a brief history, a tutorial, and 
a description of HP's Lake Stevens Instrument Division's 
experience using the technology for product development. 



by Thomas F. Kraemer 

OBJECT-ORIENTED SOFTWARE TECHNOLOGY is 
rapidly changing the way software systems are 
being designed and developed, and the way we 
think about and use computers. Over the last eight years 
HP has been active in the research and use of this technol- 
ogy. HP has completed several products that use an object- 
oriented approach, and the technology continues to be used 
in new product development. The essential idea in the 
object-oriented approach is that data and procedures are 
represented in a structure called an object, and the data is 
only accessible through the procedures contained in the 
object. Also, objects are the basic building blocks for any 
system designed using an object-oriented approach. The 
reason for such interest in this technology is that it provides 
a productive and powerful paradigm for software develop- 
ment, and it addresses such issues as code reuse and soft- 



ware maintainability. 

Since object-oriented technology requires a new way of 
thinking about software development, some questions exist 
regarding its origin, its difference from established software 
development methodologies, and the advantages it offers 
the developer and the end user. This paper addresses these 
questions by presenting a brief history and some basics 
of object-oriented technology, and a description of the de- 
sign and development of a product from HP's Lake Stevens 
Instrument Division that uses an object-oriented language. 

History 

Computer science researchers started to look at object- 
oriented concepts in the late 1960s. The concept of data 
hiding, in which data is accessed only through a well-de- 
fined interface and the data structure is unknown to the 
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Fig. 1. Chronology of object- 
oriented languages since 1960. 
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accessing routines, formed the foundation of the object 
concept. This was followed by the development of abstract 
data type systems. Abstract data types implement the data 
hiding concept and include local procedures, which have 
exclusive knowledge of the data structures within the data 
type, and therefore perform all operations on the local data. 
One of the first languages to explore and implement object- 
oriented concepts was Simula67. Simula67 was developed 
in the 1960s in Norway for modeling and simulation pro- 
grams. Fig. 1 shows a chronology of object-oriented lan- 
guages since 1960. With the exception of Eiffel all of these 
languages had their origins in a non-object-oriented lan- 
guage. Also, because the technology is still developing 
there are several competing object-oriented languages and 
no single approach has become a standard. 

Object-oriented programming gained popularity with the 
introduction of the the Smalltalk language. 1 Smalltalk was 
originally implemented as part of the research work done 
at Xerox Corporation's Palo Alto Research Center (PARC) 
in the 1970s and early 1980s. The language attempted to 
represent everything from individual bits to whole systems 
as objects. In 1981 HP Laboratories ported Smalltalk to an 
HP research computer as part of an investigation of personal 
computer environments. 2 The fine granularity of its im- 
plementation was adequate for research purposes, but be- 
cause of poor performance Smalltalk was impractical on 
generally available computers. However, many of the ideas 
demonstrated by Smalltalk are still models for today's ob- 
ject-oriented systems, and Smalltalk is being commercially 
developed on today's more powerful workstations. 

By 1983 several research and commercial organizations, 
including HP, were prototyping practical implementations 
of object-oriented languages. Most of these implementa- 
tions use a preprocessor that translates object-oriented pro- 
grams into a conventional language such as C or Pascal. 
This permits a hybrid approach in which the developer 
can choose to program in C, Pascal, or even assembly lan- 
guage when appropriate. The idea is to provide an evolu- 
tionary rather than revolutionary path toward object- 
oriented programming. The designer is able to fall back on 
established methods if the object-oriented approach causes 
problems. 

The artificial intelligence community has produced sev- 
eral object-oriented languages. The language Flavors in- 
spired a series of languages leading to the Common Lisp 
Object System (CLOS). CLOS includes object-oriented ex- 
tensions to the Common Lisp system and is primarily an 
evolving platform used by researchers. It is being designed 



Object 



as part of the ANSI X3J13 Common Lisp standardization 
process. HP played a role in the invention and development 
of CLOS. The Stanford Artificial Intelligence Language 
(SAIL) was based primarily on Algol and evolved into a 
language called Mainsail which was used in the develop- 
ment of HP's Electronic Design System. 

Pascal has been used as a foundation for several object- 
oriented languages. Additions made to Pascal to implement 
an object-oriented concept called classes resulted in the 
language Clascal and more recently Object Pascal. Clascal 
was used to develop the Lisa computer from Apple Com- 
puters. Pascal was used for an early implementation of 
HP's Softnet which influenced HP's version of Objective-C. 
HP's Objective-C modifications provided facilities to de- 
sign systems in which customers could add new features 
without requiring any changes to the original system, in- 
cluding compiling and linking. HP's use of this modified 
version of Objective-C is covered later in this paper when 
the development of HP VISTA is described. 

The C language has been used as the foundation for sev- 
eral object-oriented language implementations. The Objec- 
tive-C language, developed by Stepstone, Inc. 3 is a C prepro- 
cessor that permits intermixing standard C code with state- 
ments similar to Smalltalk. C++ 4 developed by AT&T 
Bell Laboratories is another preprocessor that generates C 
code. The latest object-oriented derivative from C is Next- 
Step which is being codeveloped by Next Computers and 
Stepstone using the Objective-C language. 

Eiffel is a relatively new language whose goal is to sup- 
port software engineering more effectively than C-based 
languages can. Eiffel is a typed, object-oriented program- 
ming language from Interactive Software Engineering, Inc.. 
It is compiled into C and comes with a class library includ- 
ing graphics classes based on XI 1 (the X Window System,® 
Version 11). Eiffel is available on HP 9000 Series 300 HP-UX 
workstations. 
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Fig. 2. Object encapsulation. The object has an internal data 
structure, which is private to the object, and methods (proce- 
dures), which have sole access to the data. 



Fig. 3. Mapping messages to code in a object. When a mes- 
sage is sent to an object the method name (selector name 
in Objective-C) is mapped to a table of pointers which point 
to the code segments for the methods. 
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Object-Oriented Technology 

Object-oriented technology includes object-oriented pro- 
gramming languages and object-oriented design method- 
ologies and processes. Because object-oriented concepts 
are so very different from conventional procedure-based 
design techniques and programming languages like C and 
Fortran, developing an object-oriented design is initially 
difficult for software designers. 

The following sections describe some fundamental con- 
cepts about object-oriented technology. Because object- 
oriented technology is rapidly evolving and researchers are 
exploring new approaches to object-oriented implementa- 
tion, there are concepts presented that cannot be fully de- 
scribed in this article. 

Encapsulation and Messaging 

In procedure-based systems, software developers are 
concerned with creating global data structures and proce- 
dures and functions that operate on the data. In an object- 
oriented environment, developers are concerned with 
using and creating objects to build a system. Objects contain 
local data structures and local procedures to operate on 
the data. The technical term for this is encapsulation.* The 
current values of an object's internal data define the object's 
current state and the object's behavior is dependent on its 
current state. The concept of data abstraction makes the 
data inside an object private and accessible only through 
one of the procedures associated with the object. Proce- 
dures inside an object are called methods. Fig. 2 shows a 
representation of object encapsulation. 

Restricting access to data in this manner may appear to 
be a serious restriction to programmers accustomed to ac- 
cessing shared data structures directly from any procedure. 
However, there are some advantages to imposing this re- 
striction: 

•This is nol the same as NewWave encapsulation described in the article "Encapsulation 
of Applications in the NewWave Environment,'' on page 57, 



objecLa 

Pointers 



Pointer to 
Inherited 
method_1 




object_b 

Pointers 



•Data structures are the same. 

Fig. 5. Simple inheritance. objecLa inherits methodj from ob- 
ject_b. 

The software can be tested more thoroughly because the 
data is private to the object and is only modified by the 
object's methods. A common source of defects in conven- 
tional software is a situation in which a shared data 
structure is modified by one procedure unknown to a 
second procedure. The second procedure then uses the 
modified data and generates errors. In contrast the defi- 
nition of the object's interface can be guaranteed to work 
when used by other objects because the data structure 
is private to the object. 

Because all data is accessed by methods associated with 
the object, the internal representation of the data struc- 
ture can change without changing any of the software 
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Fig. 4. Polymorphism allows the 
same message to be sent to differ- 
ent objects regardless of their 
internal data types and code 
implementations. 
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that uses the data. This is another common problem in 
conventional software; it can be difficult to modify a 
data structure because it requires finding and modifying 
all references to the data structure. In an object, the 
methods can be improved and become immediately 
available everywhere without having to change anything 
else. 

Objects communicate with other objects by sending mes- 
sages. An object's interface is defined by the messages that 
can be sent to it. The set of messages an object's interface will 
respond to is sometimes called an object's protocol. These 
messages cause methods to be invoked to perform various 
functions or to obtain data. A message typically consists 
of the name of the object to which the message is to be 
sent, the methods to be invoked, and any arguments re- 
quired. For example, a print message sent to an output 
object would cause the object to invoke the method respon- 
sible for doing printing. See "Objective-C Coding Exam- 
ple." on page 95 for an example of sending messages. 

This message scheme is one of the fundamental differ- 
ences between object-oriented programs and procedural 
programs. In procedural languages the routine to perform 
any function is directly invoked by another, whereas in an 
object-oriented language methods are not directly invoked. 
Each message to an object is mapped to a table containing 
pointers to the code segments for each method. Therefore, 
a method in an object consists of its pointer and code. Fig. 
3 illustrates this concept. This scheme enables each object 
to decide what specific code segment is run to fulfill an 
external request. The physical implementation of this con- 
cept varies between languages. 

Polymorphism 

Polymorphism in object-oriented methodology means 
that the same message can be sent to different objects with- 
out concern for the method implementations or the type 
of data structures in each object. Only the functional 
specifications and the message protocol for dealing with 
the object are important. The same message may yield a 
different response depending on the object receiving the 
message. For example, in Fig. 4 a message called show, 
which causes an object to display itself on the screen, is 
sent to two different objects. In objecLa the data type repre- 
sents graphic coordinates and the code performs graphics 
operations. In objecLb the data type is simply an array of 
real numbers and the code performs formatted print oper- 
ations. Note that the functional specification (i.e.. cause an 
object to display itself) and the message protocol for show 
remain the same for both objects. From this example it can 
be seen that a good application of polymorphism is an 
iconic user interface, where many different objects, deter- 
mined by the user, can appear on the screen. 

To handle different types in a procedural language, the 
programmer must anticipate and provide for all the differ- 
ent types of data structures. For example, in Pascal to con- 
tend with different data types a programmer might use an 
IF-THEN-ELSE construct or CASE statement to execute differ- 
ent procedures depending on whether the data structure 
contains integers or real numbers. This may work initially, 
but it becomes a maintenance problem if a new data type 
is added, causing the programmer to modify the program 



statements to include the new type. Then the program must 
be recompiled and reloaded. 

Inheritance and Ownership 

Object definitions can be shared and reused among ob- 

[objecl_x °bject_x 
method_1: 
a, a 2 ) 

Pointers 




object_a 




x' 



Added Data 
Structure 



[object_x 
method_1 : 
a, a 2 l 




[object_b 
new_methodl 



ob|ect_b 





new_metn<x3 



Added Data 
Structure 



(b) 



Fig. 6. Additional approaches to inheritance, (a) objecLa in- 
herits method_i from object_x. New code and data structures 
are added to object_a but the same interface to the object is 
maintained, (b) object_b inherits all the methods from object_x 
and a new method and additional data structures are added 

to objecLb. 
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jects without having to make duplicate copies. Also, the 
functionality of an object can be expanded without modify- 
ing the original object. This capability is referred to as 
inheritance — the object inherits functionality from another 
object which it can expand and build on by adding data 
and new methods. Fig. 5 illustrates inheritance: objecLb 
inherits method_1 from objecLa. The data structure in object_b 
that is used by method_1 from objecLa must be in the same 
form as in objecLa. However, the data values used by method_ 
1 in objecLb are still private to object_b. Method_1 gains access 
to the data structure in objecLb through a pointer that is set 
up when objecLb is created or by a pointer that is passed 
to it from objecLb. 

Inheritance can be implemented easily since messages 
are mapped via a table that points to what code should be 
executed. This table can just as easily point to another 
object's message table, thereby inheriting the other object's 
functionality. In some languages, like Smalltalk and Objec- 
tive-C, a strict hierarchy is imposed. Inheritance is only 
allowed from one other class of objects. Other languages 
allow objects to inherit functionality from more than one 
class of objects. Advantages resulting from being able to 
inherit functionality include: 

■ Inheritance results in a significantly smaller amount of 
code for identical functionality. This is because objects 
can be defined incrementally in terms of other kinds of 
objects. 

Inheritance can provide a convenient way of organizing 
and describing the relationships between objects. For 
example, a class of objects called "employee record" 
contains all of the generic information about an em- 
ployee such as name, rank, and serial number. If there 
are multiple types of employees such as managers, pro- 
fessionals, and nonprofessionals, a new type of object 
could be defined for each of these groups that would 
include data and operations specific to each group. For 
managers, this might be the department budget, number 
of employees, and other data that might not be relevant 
to the categories of professionals and nonprofessionals. 
Since each new object type inherits from the same em- 
ployee object definition, the generic employee methods, 
such as a request to print out the employee's name, are 
executed in the same way. These new objects do not 
need to copy or reimplement the "print" employee 
method. 
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Fig. 7. Ownership. objecLa owns objecLb. 



There are three typical approaches to inheritance. First, 
a method can be inherited from another object and used 
as is with no modifications as shown in Fig. 5. Second, 
the same method and the same interface to the method can 
be inherited and modifications to the method can be made. 
These modifications might include code to handle new 
data structures as well as the inherited data structure. The 
same interface means that the inherited and modified 
method will respond to the same messages it did before. 
This is illustrated in Fig. 6a where the same message that 
invokes method_1 in objecLx can also be used to invoke 
method_i in objecLa. Finally, all the methods of objecLx can 
be inherited and new methods and additional data struc- 
tures can be added to the inheriting object. This is illus- 
trated in Fig. 6b. 

Inheritance is sometimes confused with ownership. An 
object might own another object because the other object 
is part of its internal data (see Fig. 7). Owned objects com- 
municate with the owner with the same messages as before. 
However, the owned object is not directly accessible or 
visible to objects outside the owner. 

Class 

Many object-oriented languages allow the definition of 
a class of objects. A class is a template that can be used to 
create multiple instances. Each instance is an independent 
object with its own data and state but it shares identical 
methods with all other objects of the same class. Objective- 
C and Smalltalk support classes. 

There is not a universal agreement about the importance 
of classes in an object-oriented language. Some object- 
oriented languages are classless. These include prototypi- 
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Fig. 8. Modal analysis and testing. Every structure, such as 
a cantilever beam, naturally vibrates at several different fre- 
quencies. Such a complex structure can be modeled as an 
equivalent group of decoupled first-order systems whose 
modal parameters M, and K„ which represent the mass and 
stiffness of the beam, can be derived from a frequency re- 
sponse measurement. 
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cal languages which support inheritance, and actor-like 
languages which support concurrency but not inheritance. 

Desired Characteristics 

Regardless of the implementation, there are some charac- 
teristics that object-oriented languages and methodologies 
should have to ensure that they continue to be useful as a 
software development technology. These characteristics in- 
clude: 

■ Modifiability. It should be possible to "plug" new soft- 
ware objects into an existing system without having to 
change the original system. This allows the customer to 
enhance and expand a system just like plugging new 
hardware cards into a computer. This has been called a 
software card cage or software IC, 5 to use a hardware 
analogy. In the context of software engineering this 
means dynamically linking and loading a software mod- 
ule after the program has started running. Today, new 
functionality is normally added to software systems by 
recompiling and relinking the entire software system. 
This is a tedious and time-consuming process and usu- 
ally impractical to do by end users. Dynamic linking 
allows a user to add a new object to a system more 
quickly than relinking and reloading the entire system. 
This kind of modularity allows software objects to be 
designed in relative isolation and at different times while 
remaining compatible. 

■ Portability. Objects should be able to move from system 
to system and be usable in a wide range of software 
products. This should be as easy as the user's popping 
up a window (possibly connected over the network to 
another system), selecting the desired object, and then 
selecting what to do with it. 

■ Reusability. It should be possible for newly created ob- 
jects to have functionality that represents an incremental 
expansion of the functionality of existing objects. This 
allows reuse without having to waste extra time or mem- 
ory space to duplicate previous work. There should be 
catalogs of these standard software objects available for 
general use. 

■ Usability. At the user's request most objects should be 
viewable. With more familiarity and experience the user 
should be able to view and manipulate objects that may 
not be prominently visible to a novice user. Each object 
should be storable and retrievable by the user. The object 
environment needs to follow modern user interface con- 



ventions and de facto standards. It is widely accepted 
that objects are an excellent way to implement modern 
human-to-computer interfaces. 

■ Reliability. Since objects are fundamental system build- 
ing blocks, each object must be tested as if it were a 
complete software unit and all the standard structural 
and functional testing methods must be applied to it. 6 
Also, process and defect monitors should be built into 
every system. 

■ Performance. Object-oriented systems should not pre- 
vent the encapsulation of high-performance or highly 
tuned software. 

■ Supportability. Regression test suites must exist to retest 
objects whenever they are changed to ensure that no new 
defects are introduced and their interaction with other 
objects remains the same. This implies that objects must 
have hooks included to ensure testability. 

■ Compatibility. Object-oriented systems should work 
with existing conventional software. This is important 
to preserve previous investments and allow compatibil- 
ity with emerging software standards. 

These characteristics have been implemented in some 
object-oriented implementations and some are still topics 
of research. Together they form a vision of what object- 
oriented systems are trying to achieve. No system today 
implements everything. Formal design methods can be 
used to express and communicate an object-oriented de- 
sign. This is essential for building complex software sys- 
tems since it allows a design to be analyzed and improved 
in a systematic way. Like any other design methodology 
the successful use of object-oriented techniques depends 
on good project management and tools, such as a defect 
tracking system and configuration management. 

Recent HP Experience 

Several products at Hewlett-Packard have used object- 
oriented approaches. They include the NewWave environ- 
ment, 7 a chemical data editor, a dynamic signal measure- 
ment and analysis system, and an electronic engineering 
computer-aided design system. 

NewWave objects typically correspond to the kinds of 
data ordinarily associated with traditional office applica- 
tion programs: complete documents, spreadsheets, charts, 
drawings, and so on. The most noticeable feature of a New- 
Wave object is that a user never needs to know what pro- 
gram actually manages the object. The user simply asks to 
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perform some operation on an object and the NewWave 
object management facility (OMF) automatically associates 
the object with the correct application. 

The chemical data editor is part of an HP ChemStation 
used to perform chemical analysis. The editor portion is 
written in an object-oriented manner by using Pascal rec- 
ords as objects containing a pointer to a class dispatch 
table. Seven classes of objects represent the different data 
types corresponding to chemical spectra. The editor allows 
the user to manipulate the data. The key benefit of object- 
oriented programming to this editor is the ability to treat 
different styles of spectra (data types) in a similar way. 
This makes the manipulation of the test results much easier 
for the user. 

HP's Electronic Design System is written in the Mainsail 
language with object-oriented extensions. This system al- 
lows software objects to be created incrementally and 
linked dynamically to the existing system. Polymorphism 
is used to help implement generic routines that handle a 
wide variety of computer-aided design data. 

Recently, HP's Lake Stevens Instrument Division intro- 
duced the HP VISTA software product which is a dynamic 
signal measurement and analysis system implemented 
with the Objective-C programming language. HP VISTA is 
described in more detail in the next section. 

More HP products are under development using object- 
oriented technologies. In many cases the use of objects is not 
directly observable by the end user. In other cases the user 
has explicit control over creating and using new objects. 

Design Example 

There are no cookbook procedures or formal methods 
that can be used to generate and analyze an object-oriented 
design and this is still an area of active research. The ar- 
chitecture documented here illustrates one way of applying 
object-oriented techniques for product development. 
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Fig. 10. Typical HP VISTA display showing a virtual instru- 
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HP VISTA 

HP VISTA is the software portion of the HP 3565S Signal 
Processing System. The system is used for dynamic signal 
analysis. Real and imaginary components of electrical sig- 
nals are measured and digital signal processing techniques, 
like the fast Fourier transform, are used to calculate the 
frequency-domain components. The measured electrical 
signals can come from a wide range of sources and trans- 
ducers. Knowledge gained from these measurements can 
be used to improve a design or detect faulty machinery. 

One common application of a dynamic signal processing 
system is in the design and testing of mechanical structures 
{modal analysis). A mechanical structure, such as an 
airplane body, can be drawn on a computer-aided design 
system and analyzed with finite element methods. A pro- 
totype can be built and tested by measuring the outputs of 
accelerometers attached to different points on the structure 
while shaking the structure with a random input. 

The random input has a broad bandwidth and will cause 
all of the modes of vibration of the structure to be excited. 
The frequency spectrum plot of each transducer will peak 
at a frequency associated with the natural vibration of the 
structure. A structure can be formally modeled by param- 
eters that describe each mode of vibration (see Fig. 8). The 
resulting modal model is useful for simulating modifica- 
tions to the structure. 

The HP 3565S hardware (see Fig. 9) provides a rack that 
can hold up to sixty-three input modules. Each input mod- 
ule contains analog-to-digital converters for data acquisi- 
tion, memory buffers for one or more input channels, and 
hardware dedicated to digital filtering and zoom analysis. 
The master module contains a dedicated 16-bit processor 
and additional digital signal processing hardware to fetch 
data from each input buffer for windowing, transforming, 
and uploading data to a host computer via an HP-IB (IEEE 
488, IEC 625) interface. 

The HP VISTA software resides on the host computer 
and provides the user interface and processes for interac- 
tive control of the measurement and analysis functions and 
stimulus-response testing. It is also responsible for down- 
loading software to the master module in the signal process- 
ing hardware. The host computer is an HP 9000 Series 300 
Computer running the HP-UX operating system. The multi- 
tasking capabilities of the HP-UX operating system allow 
HP VISTA to perform several measurements simultane- 
ously, plot results, write a report, and receive electronic 
mail from a local area network. Measurement results can 
be used directly by the design and analysis tools. The HP- 
UX system also provides real-time extensions such as a 
preemptive kernel, shared memory, and memory lockable 
processes, which are required to handle instrument I/O. 

Selection of an Object-Oriented Language 

The developers of the HP VISTA product had previous 
experience with several large instrument firmware projects 
written in Pascal. The complexity and size of HP VISTA 
required a new software engineering approach. Since the 
range of applications for dynamic signal analysis is very 
large, the major goals for HP VISTA were to provide a 
system that enabled customers to configure their own soft- 
ware and add new hardware into the system. It was also 
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important to be able to add new features to the product 
incrementally. 

Object-oriented software was able to satisfy these goals. 
The HP VISTA product was initially based on the Softnet 
technology developed by a group at HP's Ft. Collins En- 
gineering Operation. These concepts were ported to C for 
compatibility with the HP-UX system. This C-based object- 
oriented system was enhanced to include encapsulation, 
messaging to support polymorphism, and inheritance. 

During the early development stages of HP VISTA, a 
group at HP's Loveland Measurement System Operation 
was using and and extending the Objective-C programming 
language. The HP VISTA C code was ported to Objective-C 
halfway through the project to permit sharing of code and 
ideas with other HP development groups. Software en- 
gineering issues such as source code control and configura- 
tion management were worked out in parallel (see "Object- 
Oriented Life Cycles" on page 98). 

Faceless Instruments 

The use of a general-purpose HP workstation as the pri- 
mary interface to instruments is a fairly new concept. In- 
struments traditionally have been contained in a dedicated 
box with a display and buttons on the front panel for control 
and observation. The development of the HP-IB interface 
permitted these stand-alone instruments to be controlled 
from a central computer, but the primary interface re- 
mained via the front panel. 

A "faceless" instrument transfers the primary interface 
from the front panel of the instrument to the screen of a 
general-purpose computer. This makes it easier to interface 
with a group of instruments, and it is a lower-cost solution 
since it eliminates the redundant displays and front panels 
on each instrument. The HP PC Instruments 8 family was 
the first HP product line to build faceless instrument mod- 
ules with the user interface displayed on a personal com- 
puter screen. These software displays mimic the buttons 
and displays seen on a normal instrument front panel. 

HP VISTA software also controls a group of faceless in- 
struments that can support hundreds of input channels. 
Because of the number of input channels, the HP VISTA 
computer display cannot duplicate a standard front panel 
on its smaller display. A method was devised for control- 
ling and viewing measurement activity via a windowed 



user interface {see Fig. 10). HP VISTA does this by using 
the standard HP Windows/9000 system. Each object in HP 
VISTA is capable of displaying itself in a window on the 
screen. The user can also have other software applications 
displayed simultaneously in other windows. For example, 
the user can view a drawing of a device while performing 
measurements on it. It also allows the user to reconfigure 
the display as required since windows can be added, de- 
leted, and moved to different regions on the screen. 

The user interface required several iterations to achieve 
the goals of user configurability and ease of use. One ver- 
sion of the design considered use of the entire display filled 
with tiled* information. The display tiles are nonoverlap- 
ping and adjust in size if additional tiles are added to the 
screen. The advantage to this approach is that it provides 
the user with a consistent view of the system. The disadvan- 
tage is that it is difficult to add new objects as they are 
developed and the user may not want the exact display 
chosen by the program. Another design proposed to display 
every object in a directory from where it could be selected 
and displayed. The advantage here is total flexibility. The 
major disadvantage is confusion by new users on where to 
start work. Also, each window creates a new HP-UX pro- 
cess, and too many processes can reduce system perfor- 
mance. The final design for the user interface settled on 
limiting the display windows to a small number of objects 
and tiling objects within these windows in a controlled 
manner. Different-sized displays can be accommodated 
with this technique and still provide the user with the 
advantages of windows. 

Object Model/View/Controller 

The HP VISTA system is based on three types of objects: 
model objects, view objects, and controller objects (see Fig. 
11). This organization is similar to that used in the 
Smalltalk language. 

In HP VISTA, model objects contain data about the 
hardware, data collected from measurements, and data as- 
sociated with computations. They also contain the methods 
to retrieve and manipulate the data. View objects own 
model objects and they contain the methods to draw the 
information contained in the model objects on a display. 

•Tiled information refers to a window system in which windows are shaped and sized to 
fit together without overlapping each other 
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Objective-C Coding Example 



The HP VISTA software is written in the Objective-C program- 
ming language. Standard C code can be freely intermixed with 
Objective-C code because a preprocessor translates Objective- 
C code into standard C. Message expressions are written as a 
pair of balanced square braces surrounding the receiver, selec- 
tor, and arguments. 

[receiver selectorargument] 

The receiver is the name of the object that will receive the 
message. The selector is the particular method that should be 
performed by the receiver Arguments are parameters which can 
be either simple data or other objects. 

Message expressions are allowed anywhere function calls are 
allowed in C. For example, a message expression can appear 
as arguments in the standard C print function: 

printf("The size of the set is %dn", [aSet size]); 

The standard C function, printf, will print out the string, "The 
size of the set is N", where N is the number returned from the 
object aSet after the method size is executed. 

Other objects can be sent along with the message as argu- 
ments with the following syntax: 

[anObject do:arg1 with:arg2) 

This statement says to select the method do:with: from the object 
anObject, and use arguments argi and arg2. For example, to sum 
two coordinate point objects, coordx and coordy, they could be 
sent to a summation object aSum with the message: 

[aSum x: coordx y: coordy] 

The Objective-C preprocessor converts this syntax into stan- 
dard C function calls. The preprocessor also maps these mes- 
sages into a more efficient form than if the function calls had 
been written directly using string values. Also, because the mes- 
sages are symbolic and do not refer to any specific function, 
they can be dynamically bound to any particular function at run 
time. This permits the efficient implementation of inheritance, 
polymorphism, and the ability to link and load new objects dynam- 
ically. 



View objects send messages to model objects to retrieve 
the information to be displayed. 

With the model object separated from the view object 
each can specialize in what it does best. A single model 
object can be viewed in more than one way by creating 
multiple view objects that own the same model object. In 
Fig. 12 a single model object that contains the current value 
of the time of day is owned by two view objects. The view 
objects use the time-of-day value from the model to display 
two different representations of the time on the display. 
Likewise, a single view object can be used to display many 
different model objects. Because of the dynamic linking 
and loading capability of objects, new objects can be dynami- 
cally added to a view object, thus eliminating the need to 
provide for all combinations of models and views. 



The controller object handles all of the user's input de- 
vices, such as the mouse and keyboard. The controller in- 
terprets the user inputs and maintains information about 
the state of the input devices. The inputs can even come 
from a computer-generated source such as an automatic 
test program. A standard controller object can be used by 
many different view objects. 

Views and Subviews 

HP VISTA has several general classes of view objects 
that are widely reused either through inheritance or simply 
by reusing the whole object. These view objects include 
text displays, scroll bars, pushbuttons, and so on. A win- 
dow display can be constructed from several of these view 
objects in a hierarchical manner. The subviews of a view 
object are owned by and nested within the view when it 
is displayed (see Fig. 13). Subviews are usually added to 
a view when it is created and are set up to display the 
individual objects that make up the model object. 

Each view has the ability to calculate its size automati- 
cally from the positions and sizes of its subviews. This 
permits subviews to change in size without requiring any 
changes in code. A subview can operate as it would by 
itself, or it can transfer responsibility to its superview. This 
allows general-purpose subviews to be created which can 
be selectively overridden by the superview. 

Dependent View Objects 

Each view object can automatically update the display 
whenever the model object changes. The model object 
maintains a list of all objects that want to be informed 
whenever a change takes place. This list is called a depen- 
dency list. An object can request to be added to this list 
by sending a message to the model object it wants to be 
notified by when something changes. HP VISTA added this 
capability to the Objective-C system. 

Exception Handling 

To prevent the system from crashing because of errors 




Fig. 12. Two view objects own the same model object. The 
model object contains the current time of day. One view object 
displays the time in analog format and the other view object 
displays the time in digital format. 
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in user input or measurement computations, Objective-C 
was extended to include a try/recover exception handling 
capability. Different sections of the code are declared a try 
region, where if anything disrupts the normal sequence of 
processing, such as division by zero or a hardware error, 
the recover block of code is executed either to patch things 
up and continue, or to inform the user that a problem exists. 
Every attempt was made to provide the user with helpful 
error messages so that any problem can be corrected and 
a successful measurement made. 

A try/recover block was also placed around the entire 
HP VISTA system. The system is then protected against all 
undetected software defects. These defects are trapped and 
the user can continue to operate the system. Some of these 
undetected defects might cause the system to freeze up and 
require the user to restart the program. Despite rigorous 
quality assurance testing, it is well known that software 
defects can remain undetected for a long time. Object- 
oriented programming improves this situation but it will 
not guarantee zero defects. 

HP VISTA Architecture 

Between the model and view object categories, HP VISTA 
has more than 300 different types of objects, which are 
further categorized into three groups: virtual instrument 
objects, measurement objects, and result objects. Each 
group is made up of model and view objects, that is, there 
are virtual instrument model and view objects, measure- 
ment model and view objects, and result model and view 
objects. These categories and the relationship between the 
objects and the display windows are shown in Fig. 14. 

Virtual instrument objects encapsulate the instrument 
hardware, which includes input modules, source modules, 
and the hardware configuration setup. All of the software 
in HP VISTA interfaces with the hardware via the virtual 
instrument objects. 

The measurement objects perform generic measurement 
functions such as arm, pause, continue, abort, and averag- 
ing, as well as functions specific to a particular measure- 
ment type. Typical measurement types include frequency 
response functions and power spectrums. 

The result objects store the computed measurement data. 
This data is corrected for calibration variances and is avail- 
able for display by various view objects. The result objects 
can also be used for additional computation and processing 
by the user. 

The measurement folder, which appears in the virtual 
instrument display window, lists all of the measurement 
objects accepting data from the virtual instrument (see the 
bottom window in Fig. 10). The user can request that mul- 
tiple measurements be computed simultaneously from the 
data collected by the virtual instrument objects. 

A standard interface is defined between the virtual in- 
strument objects and measurement objects as well as be- 
tween the measurement objects and the result objects. These 
interfaces permit one category to change its implementation 
without affecting the other two categories of objects. For 
example, as new instrument hardware is introduced, only 
the virtual instrument objects need to change. The measure- 
ment and result objects can remain the same. 



Virtual Instrument Objects and Dependency 

All instrument hardware handled by HP VISTA is encap- 
sulated by virtual instrument objects. The term virtual in- 
strument was chosen to represent the fact that the software 
representation is a virtual image of the instrumentation 
hardware. The letters of the word VISTA stand for Virtual 
Instrument System for Test and Analysis. The virtual instru- 
ment objects encapsulate the hardware setup state, the input 
module states, and source module states. 

Virtual instrument objects read and update the state of 
the hardware. HP VISTA's object dependency feature de- 
scribed in a previous section is used to automate updating 
these objects whenever the state of the hardware changes 
or new modules are added. The use of dependency elimi- 
nates the need for each object to poll periodically for any 
changes. 

Each hardware input module is represented by an input 
module object. Input module objects are displayed in the 
input setup window. When an input module object changes 
for any reason, it informs the appropriate virtual instrument 
view object that a change has occurred. The virtual instru- 
ment view object can then take appropriate action. A com- 
mon use for this scheme is to indicate when a new block 
of data has been acquired. The input module loads its buffer 
memory and signals all of its dependent objects that it has 
new data. The objects signaled can then choose to use or 
ignore the new data. 

A standard interface exists between the virtual instrument 
objects and measurement objects. The virtual instrument 
collects one block of data from each input module and 
creates an object containing an array of data block objects. 
This general-purpose object contains the data from the input 
module object and methods for performing measurement 
calculations (e.g., add two blocks of data, complex conjugate 
addition, etc.). This object can be used by all measurement 
objects. Measurement objects can also make requests to the 
virtual instrument objects to activate instrument source 
modules through a standard protocol of messages. 

Concurrency 

The process of collecting data and passing it on for further 
computation is effectively an endless loop. A deferred mes- 
saging system was created in HP VISTA to allow messages 
from the user to be executed while a measurement is taking 
place. For example, the user may wish to change the voltage 
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Fig. 1 3. Display window constructed out of view and subview 
objects. 
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setting of a source output while performing some measure- 
ment process. Instead of forcing each object to waste CPU 
time in a software loop that polls for new messages, a 
deferred message queue was created. This queue is a list 
of messages waiting to be executed. 

All messages sent to objects on the dependency list are 
sent to this deferred message queue. Also, all messages that 
result from the user's pushing a button or selecting a menu 
item are sent to this deferred message queue. The main 
measurement loop is divided so that a deferred message is 
sent frequently enough to objects on the dependency list 
to allow a user's message to be executed in a timely fashion. 
This creates the illusion of two operations occurring at the 
same time even though there is only one program and one 
HP-UX process. Users can modify and display instrument 
settings interactively while watching on-line updates of 
the measurement in progress. The spawning of extra pro- 
cesses is not required and objects do not need to poll for 
input — they just need to respond to messages sent to them. 
Significant performance advantages are achieved by reduc- 
ing the number of processes required. 

Measurement Objects 

Measurement objects perform specific measurement 
functions using the data collected by the virtual instrument 
objects. The concept of inheritance is used by all measure- 
ment objects to provide new measurement functions incre- 
mentally. All measurement objects inherit key functional- 
ity from a super class object which implements a state ma- 



chine that handles all generic measurement functions, such 
as arm, pause, continue, abort, and averaging. 

Several different measurement objects can make them- 
selves dependent on the virtual instrument objects. Each 
time a new set of data has been collected, a virtual instru- 
ment object informs each object on its dependency list that 
new data is available. More than one measurement object 
can be on a dependency list to permit the simultaneous 
calculation of several measurement results from the same 
data. 

One specific measurement performed by HP VISTA is a 
multiple-input, multiple-output (MIMO) frequency re- 
sponse function. There is a significant increase in measure- 
ment throughput and measurement accuracy associated 
with processing multiple simultaneous inputs. The calcu- 
lation of this measurement requires a matrix computation 
combining data from multiple channels. 9 The MIMO fre- 
quency response measurement object uses the data col- 
lected by the virtual instrument objects to do these compu- 
tations. 

Other measurement objects perform 1/3-octave measure- 
ments, power spectrum measurements, and time-domain 
measurements. Depending on the application, one or more 
measurement objects might be using the virtual instrument 
output simultaneously. These measurement objects are set 
up and started in measurement windows on the display. 
The measurement windows sometimes contain views of 
the measured results. 

(continued on page 99) 
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Fig. 14. HP VISTA architecture. 
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Object-Oriented Life Cycles 



An independent metrics group was formed early in the HP 
VISTA development process to help measure and improve the 
software development process. 1 It was not clear whether an 
object-oriented development process would fit into a conven- 
tional software development life cycle. Some of the life cycle 
models considered included: 

■ A code and fix model — write some code and fix the defects 
found. Detailed design is not considered at the beginning. 

a A stagewise and waterfall 2 model— separate the development 
process into a design phase, a coding phase, and a testing 
and integration phase. 

■ An evolutionary development model — incrementally build 
rapid prototypes to gain early user feedback for subsequent 
improvements and evolution. This approach can easily have 
all of the problems of the old code and fix model. This is a 
popular approach with fourth-generation languages and spread- 
sheet applications when the developer does not know what 
is required until the solution is shown. 

■ The transform model — develop a formal specification that is 
transformed into an optimized implementation. The objective 
is to have an implementation that can be proved correct and 
error-free. This method is primarily an area of research. 
Previous project experience indicated that none of these ap- 
proaches was a total solution. A common belief shared by the 
design team was that code should be quickly prototyped to gain 
operational understanding and experience and then thrown out. 
The code can then be rewritten and constructed in a cleaner 
and more organized fashion based on the quick prototype experi- 
ence. The only problem with this approach is that because of 
the pressure to release a product quickly the prototypes might 
be shipped, resulting in maintenance problems because early 
prototypes typically consist of patched and poorly structured 
code. 

In addition to creating and managing a development life cycle 
other goals of the metrics program were to develop methods to: 

■ Show the progress of a project throughout different phases in 
its life cycle. 

■ Indicate when a project had passed from one phase of the 
life cycle to the next. 

■ Monitor changes to the product's definition, internal design, 
and code. 

■ Improve resource and schedule planning to help coordinate 
project staffing, determine development costs, and forecast 
future schedules. 

■ Flag any new process problems that a project might have. 

It was made clear to the design team that the metrics program 
was designed to measure projects and processes and not indi- 
vidual performance. The goal was to determine ways in which 
the process could be improved rather than find out who was 
writing the most code. This noncompetitive approach along with 
an independent metrics group was considered essential to ac- 
quiring good, nonbiased information to improve the software de- 
velopment process continually. 

A waterfall model, modified to take into consideration the needs 
of object-oriented development, was used to define our develop- 
ment life cycle. The major phases included: 
ci Definition phase, in which the external specifications of the 

product functionality are defined. 

■ Design phase, in which the system design is partitioned into 
objects and the internal design and functionality of each object 
are defined. 

■ Coding phase, in which the objects and other modules are 
created, tested, and debugged. 



■ System testing phase, in which independent testing of the 
entire product is performed During this phase the system is 
100% functional with some bugs and performance problems 
remaining. 

■ Production release phase, in which the product is released 
with no remaining known defects and an acceptably low defect 
rate. 3 

For each phase metrics were defined and collected to deter- 
mine if that phase was completed (see Table I). To encourage 
minimum development time, different parts of the project were 
allowed to be at different points in the life cycle. Graphs of the 
metrics collected were used by management for planning pur- 
poses and detecting process problems. 



Table I 

Software Metrics Set by Life Cycle Phase 

Definition Phase: 
Cumulative Engineering Months 

Design Phase: 
Above Set, plus 

Object Classes Planned, Designed 

Methods Planned, Designed 

Productivity: Engineering Months/Classes Planned 

and Designed 
Productivity: Engineering Months/Methods Planned 

Coding Phase: 
Above Set, plus 

Object Classes Tested, Released 

Methods Coded, Tested 

Total KNCSS (Thousand Lines of Noncomment 

Source Statements) 
Link Success Rate 
Compile Success Rate 
HP-UX make Time 

Productivity: Engineering Months/Classes Released 
Productivity: Engineering Months/Methods Released 
Productivity: Engineering Months/KNCSS 

System Testing Phase 

Above Set, plus 

Defects Found, Resolved 

Cumulative Defects versus Cumulative QA Hours 

Defect Finding Rate 

Estimated QA Hours Remaining 

QA Hours Per Week 

Unresolved Defects by Severity 

Over All Phases: 

Cumulative Engineering Months 
Productivity: Engineering Months/Classes Released 
Productivity: Engineering Months/Methods Tested 
Productivity: Engineering Months/KNCSS 
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Result Objects 

Results computed by the measurement objects are stored 
in special result objects that include special information 
about the measurement. This information includes data 
correction information, units, input range factors, pointers 
to where the measurement is documented, and so on. The 
result objects inherit functionality from general-purpose 
math objects. These results are displayed in result and trace 
view windows. 

Result objects can be saved on disc by using an automatic 
I/O feature of HP's Objective-C. Every object in HP VISTA 
has the ability to save itself on request. The save procedures 
are nested so that a single message to an object will save 
the object and all of the objects it uses. Therefore, the user 
can save just the results, the virtual instrument setup ob- 
jects, the measurement setup objects, or everything except 
the actual hardware. 

Each result view object can be a dependent of a result 
model object. Separating the view function allows each 
measurement result to be displayed in more than one way 
by creating a new view object. Also, more than one view 
object can be simultaneously displaying the measurement 
results. Each time the measurement object computes a new 
result, it sends a message to a result model object informing 
it that there has been a change. The result model object 
then informs all of the result view objects on its dependency 
list that it has new results. The result view objects can then 
take the new results and update the trace plots in the dis- 
play windows. For example, a user can be viewing the 
same measurement results both as a frequency response 
plot and as a Nyquist plot in two different windows. 

The user of HP VISTA has a large amount of control over 
what measurement objects and results objects are created 
and displayed. This makes setting up a custom measure- 
ment display easy. The user can open the specific measure- 
ments and results views required and position these on 
the screen where desired using standard HP Windows/9000 
menu commands. For users not requiring this flexibility, 
objects can be created that will manage and perform a spe- 
cific measurement application. These applications require 
less knowledge about the windows and object system and 
are easier to use. 

A user programming language is provided by HP VISTA 
to permit users to send messages to any object visible in 
the system. With this feature the user can create automatic 
scripts to set up and perform measurements without human 
interaction. The user can also create a user program to 
process the results further if required by the application. 

Performance 

Since HP VISTA measurements must be performed in 
real time and on-line, consideration was given to designing 
the system for performance. Common folklore says that 
object-oriented systems are slower than conventional sys- 
tems because data can only be accessed by sending a large 
number of messages. 

HP VISTA was designed with an object-oriented lan- 
guage that permits the inclusion of standard C code where 
required for performance reasons. Early in the design an 
estimate was made concerning what items should be ob- 
jects and what items should be coded in C to increase 



performance. For example, direct pointing into an array of 
numbers was allowed in a controlled manner since millions 
of array computations are performed. 

Most of the anticipated bottlenecks did not become prob- 
lems. Optimization work on the Objective-C language by 
Stepstone Corporation and a group within HP resulted in 
message execution times only a fraction slower than a stan- 
dard procedure call. Several major performance problems 
were solved during a tuning phase by modifying the offend- 
ing algorithms and repartitioning some objects. Perfor- 
mance was also improved by measuring and determining 
where the bottlenecks were and then rewriting those sec- 
tions of code. This included eliminating objects in some 
places and creating new objects elsewhere. 

A common design issue related to object-oriented pro- 
gramming is the granularity of objects created. A fine-grain 
object is one that performs a very small function in the 
overall system. A large-grain object is one that encapsulates 
a large amount of functionality. A common perception says 
that a system with fine-grain objects will have poor perfor- 
mance because of the large number of messages required. 
On the other hand, a system with too many large-grain 
objects will not provide the user with many of the advan- 
tages of objects. 

HP VISTA designers discovered that both large-grain and 
fine-grain objects must be carefully chosen and designed 
to balance system features with performance. Granularity 
is an important system design issue that is still not well- 
understood. For example, a very fine-grain integer object 
was created to aid in the display of integer numbers on the 
screen. This object turned out to be a good use of an object 
since it was able to fit into the standard view object struc- 
ture and was updated automatically at a fairly low fre- 
quency. Only a couple of messages are sent to it and so it 
is not a performance bottleneck. However, this is a poor 
object to use in a numerically intensive application such 
as a fast Fourier transform which requires fast and frequent 
access to each integer value in an array. A faster design 
would create an object with a fast Fourier transform method 
coded using an array of integers rather than an array of 
integer objects. This array of integers would be classified 
as a coarser-grained object. 

Additional performance tuning was done with HP 
VISTA's interface to the HP Windows/9000 system and the 
HP-UX operating system real-time extensions. An addi- 
tional memory-locked process was created to store incom- 
ing blocks of data into an area of memory shared by the 
main HP VISTA program. This memory queue buffers the 
statistical time variations caused by hardware and operat- 
ing system response time. 

Memory Management 

The creation and destruction of objects requires that sys- 
tem memory be allocated and deallocated. These actions 
can result in two problems: memory can be fragmented 
into small and unusable pieces, and memory can run out 
because memory space occupied by old objects is not re- 
claimed. The process of cleaning up memory is often referred 
to as garbage collection. The program must periodically 
reconfigure system memory space to avoid running out of 
memory for new objects. 
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The garbage collection process can take a significant 
amount of time and could interfere with a real-time mea- 
surement process. HP VISTA designers carefully designed 
the main real-time measurement loops so that memory 
management is not required during operation. This is done 
by recycling old objects every time through the measure- 
ment loop and avoiding the creation or destruction of new 
objects. Outside of the measurement loop, a simple memory 
garbage collection takes place in the background. The user 
can also request a more complete garbage collection when 
spare time is available. 

Summary 

Object-oriented technology represents a fundamentally 
new way of creating software. It has not yet been quantified 
into a textbook procedure. To be successful, object-oriented 
approaches must be applied in conjunction with good proj- 
ect management and tools, such as a defect tracking system 
and configuration management. There are no panaceas that 
will eliminate software engineering problems, but object- 
oriented approaches will help produce software that is far 
more tolerant of change. HP VISTA and other HP products 
are examples demonstrating these advantages. 
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